[ZODB-Dev] Commit or lock object accross transactions

[Christian Reis]

On Wed, Jul 16, 2003 at 08:05:52PM +0200, Roché Compaan wrote:
> I am not too concerned about orphaned ids so the BTrees Length class
> would be the simplest solution for me. You seem to have tougher
> constraints to navigate, so good luck :-)

Length mitigates the problem with orphaned IDs by postponing the
definition of the definitive ID to commit() time (compared to a locked
global which would give you the definitive ID beforehand).

It however causes the ID to change upon commit when there are conflicts
(which was my third constraint).

Of course, if you undo a certain transaction then you will definitely
have an orphaned ID that isn't going to be very easy to reap and reuse.

> It seems that a locking primitive could be very useful specifically for
> generating sequential unique object ids. Wouldn't it be possible to
> prevent orphaned ids if clients requesting ids are queued. If a client
> is in front of the queue it locks the object counter, get a new id and
> releases the lock. It don't think this will be trivial to implement
> though.

Even if the requests were queued, you don't know if one of the clients
in the middle is going to decide to give up on its transaction. Orphaned
IDs never happen unless somebody changes their mind about an ID *after*
acquiring the *definitive* one.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL