[Zope] Locks?
Phillip J. Eby
pje@telecommunity.com
Wed, 10 Nov 1999 22:54:05 -0500
At 02:47 PM 11/11/99 +1100, Stuart 'Zen' Bishop wrote:
>
>If you have your lock as a module level variable, I believe it will
>work. Either have all instances sharing the same lock or store a dictionary
>of locks. This should be fine unless you need to maintain a lock between
>Zope restarts in which case your lock could be any object with a known id
>in a folder (as only one thread can create the object, and the others fail),
>and delete it to unlock.
Um, that would work for human-scale locking. (E.g., I want to edit object
X, so lock it so others can't). But for locking *within* a transaction, it
won't necessarily work as you want. Thread A will create the object, and
so will thread B. They both think they own the "lock", so they proceed on.
One of them then gets rolled back at commit time due to a ConflictError.
If you are only making changes to things in the ZODB, that's fine, since
everything is rolled back. But if you're guarding access to say, a file or
some other external thing, you can still collide any time up until
transaction commit.