[ZODB-Dev] Commit or lock object accross transactions

[Christian Reis]

On Wed, Jul 16, 2003 at 06:01:38PM +0100, Toby Dickenson wrote:
> On Wednesday 16 July 2003 17:49, Christian Reis wrote:
> > On Wed, Jul 16, 2003 at 05:33:02PM +0100, Toby Dickenson wrote:
> > > If you only need a small number of unique ids then there may be a cheeky
> > > option..... the method for allocating ZODB OIDs has all of the
> > > characteristics that you need. You could use an oid of a newly created
> > > object as your unique id, or call the storage.new_oid method directly.
> >
> > Why only "a small number"?
> 
> There is a limited supply of 2^64 over the life of a storage. Im not sure what 
> happens after that, but its bound to be bad.
> 
> I guess you are unlikely to hit that limit unless you need *huge* numbers of 
> unique ids. Be careful not to expose yourself to a denial of service attack, 
> if untrusted users can assign large numbers of unique ids.

    >>> 2L ** 64 
    18446744073709551616L

Well, 2^64 isn't *too* small :-) 

You suggested before using new_oid() to get an ID. However, I don't see
how that could be used to guarantee a sequential ID (since I do expect
other objects will be stored in the same database); the only way would
be using _p_oid itself. This presents the problem that _p_oid is only
assigned when the object has been comitted once (even if it *is*
a commit(1)), which may be too late for the application's requirements.

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