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.
On Wed, Nov 10, 1999 at 10:54:05PM -0500, Phillip J. Eby wrote:
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.
If I force a commit after object creation, would that work? -- Benno Rice "No, no. We're *sweet* and XNFP Aries Dark Subculture- *innocent* evil bastards." friendly Internet Geek benno@netizen.com.au "Defend your joy"
participants (2)
-
Benno Rice -
Phillip J. Eby