[Zope] Locks?

[Benno Rice]

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"