[ZODB-Dev] Commit or lock object accross transactions

[Roché Compaan]

* Shane Hathaway <shane at zope.com> [2003-07-28 20:56]:
> Roché Compaan wrote:
> >* Roché Compaan <roche at upfrontsystems.co.za> [2003-07-16 20:00]:
> >
> >>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 :-)
> >
> >
> >Just some feedback. We implemented and object id service using
> >BTrees.Length and I'm sorry to say that it doesn't scale very well. It's
> >ok when you have 2 threads but anything above that and you can be sure
> >that you will get duplicate ids.
> >
> >In a test with 10 concurrent clients each continually asking for ids
> >until they have a 100 ids we got 37 duplicates out of a 1000. You might
> >just as well start up your Zope server single threaded :-(
> >
> >Any other ideas?
> 
> Well, seriously, calling self._p_jar.new_oid() ought to work pretty 
> well.  You'll only exhaust the OID space if you make 1 billion IDs per 
> second consistently for the next 500 years. ;-)
> 
> Alternatively, you could add a new "sequence generator" interface to 
> your ZODB storage.  It would be generally useful.

I am curious as to why actually this guarantees unique ids. I used
exactly the same thread locking that is seen in new_oid and I still got
duplicates. _p_jar.new_oid won't work for our app because I need
sequential ids per meta_type - I'm not too worried about orphaned ids
though.

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za