I've got a situation where I'd like to be able to have a mutex lock. Unfortunately, I can't use Lock objects out of the thread module as they appear to be unpicklable. Does Zope have any mutex objects I can use? -- 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"
[slowly moving this to zope-dev]
I've got a situation where I'd like to be able to have a mutex lock. Unfortunately, I can't use Lock objects out of the thread module as they appear to be unpicklable.
Code your own module (for my Shrubbery product I called it ShrubLock) which has its own acquire() and release() calls. If you need lots of locks, hack extra stuff into the module and pickle something like an ID. I considered using an MD5 hash of the object URL. Note that this is NOT enough to avoid Z2 CONFLICT errors, as Zope does enough stuff after leaving the methods in your object that there's plenty of time for another transaction to start on the same object. This seems to be a fundamental problem with Zope and needs some serious work on Zope's guts to be resolved. DC apparently advise anyone with write-intensive needs to use non-ZODB storage. Unfortunately, as far as I can tell, "write-intensive" devolves to *any* two modifications at once if you're doing stuff like trying to maintain a ZCatalog of your web site by having your CatalogAware objects call reindex_object(). ZCatalog fans, you better use a cron job to trigger regular re-indexes if your site is going to be at all busy. Regards, Garth. -- <gtk@well.com>
On Thu, 11 Nov 1999, Benno Rice wrote:
I've got a situation where I'd like to be able to have a mutex lock. Unfortunately, I can't use Lock objects out of the thread module as they appear to be unpicklable.
Does Zope have any mutex objects I can use?
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. ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
participants (3)
-
Benno Rice -
gtk -
Stuart 'Zen' Bishop