What prevents id collisions in Zope? It looks like the the ObjectManager.py code checks to see if the id is taken, and then it reserves the id. Is there a danger that 2 processes/threads (z2.py -t 4?) could both check and reserve the same id? Is there something in Zope that prevents this (improbable, but perhaps possible) problem? Is there certain way to find an object id that is not taken?
David Binger wrote:
What prevents id collisions in Zope?
An "Optimisitic Colision Resolution Protocol"
It looks like the the ObjectManager.py code checks to see if the id is taken, and then it reserves the id.
Right.
Is there a danger that 2 processes/threads (z2.py -t 4?) could both check and reserve the same id?
Yes. One thread will win, and one thread will loose. The winner will get the new id. The looser will try again. The looser will find out when it tries again the the id it wants is taken, and will report that to the user. The user picks another id.
Is there something in Zope that prevents this (improbable, but perhaps possible) problem?
No, but a programatic resolution protocol is planned for future releases of ZODB.
Is there certain way to find an object id that is not taken?
The chances of colision are very small unless you have an incredibly write intensive application (which is not ideal for ZODB filestorage. In that case, you should store your information in a RDBMS). This the "optimism" in optimistic. -Michel
Michel Pelletier wrote:
David Binger wrote:
What prevents id collisions in Zope?
An "Optimisitic Colision Resolution Protocol"
OCRP ... pronounced 'Oh Crap' by any chance? -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
participants (3)
-
Bill Anderson -
David Binger -
Michel Pelletier