[ZODB-Dev] Commit or lock object accross transactions

[Toby Dickenson]

On Monday 28 July 2003 22:42, Shane Hathaway wrote:
> Roché Compaan wrote:
> > * Shane Hathaway <shane at zope.com> [2003-07-28 20:56]:
> >>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. ;-)
> >
> > 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.
>
> It works because OIDs are managed centrally by the ZEO server and fall
> outside transaction scope.  It's also reasonably fast because clients
> request blocks of OIDs rather than single OIDs.

A constraint mentioned earlier in this thread is that numbers are assigned in 
order. The oid assignment policy is efficient because it can break this rule. 
For example, the zeo server may assign oid band 6000:6100 to one zeo client, 
and 6100:6200 to another. There is every chance that oid 6100 will be 
assigned to an object by the second client long before 6099 is assigned by 
the first.


-- 
Toby Dickenson - http://www.geminidataloggers.com/people/tdickenson

Want a job like mine?  http://www.geminidataloggers.com/jobs for Software
Engineering jobs at Gemini Data Loggers in Chichester, West Sussex, England