RE: [Zope] persistent object with non-persistent attributes
Thinking aloud: ...so myNonZopeClass instances need to be a singleton-like thing, with some sort of mutex-ish of lock to prevent other instances from being constructed? I wonder if there is a way to throw an exception on construction of a myNonZopeClass instance if another Zope thread has an instance. Perhaps you could keep an external boolean lock variable in a module-level global accessible to all threads, but it might just be easier to follow Toby's suggestion and just see if you can keep your myNonZopeClass instance object in a module-level global, and just keep a reference to it in a _v_ attribute? I've never tried anything like this, might something like this possibly work? Sean -----Original Message----- From: Jerome Alet [mailto:alet@librelogiciel.com] Sent: Tuesday, March 04, 2003 2:15 AM To: Toby Dickenson Cc: zope@zope.org Subject: Re: [Zope] persistent object with non-persistent attributes On Tue, Mar 04, 2003 at 09:30:53AM +0000, Toby Dickenson wrote:
On Tuesday 04 March 2003 9:22 am, Jerome Alet wrote:
Zope uses (by default) four publishing threads. That means you will get four copies of your objects in memory at any one time (or 8, if you have 2 zeo clients). You also have the possibility of ZODB choosing to deactivate your object, so all attributes are lost from all 4 of those objects.
'hardware plug&play' makes me think this is this what you want... Perhaps storing this special object in a module-level global would be better?
but I must be sure that only one thread deals with the hardware at a time.
myZopePersistentClassInstance.complexAttr = myNonZopeClass()
but this will probably, if it works, bloat by ZODB.
is there a way to do this without suffering from severe bloat ?
myZopePersistentClassInstance._v_complexAttr = myNonZopeClass()
will exclude that attribute from ZODB processing.
This is perfect ! But now how can I be use that no other thread access the hardware at the same time ? (if possible a single device open at Zope start or on-demand would be fine) I actually use a CGI script for this, but I wondered if using Zope instead wouldn't make it more "reactive". Thanks in advance. Jerome Alet _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Tue, Mar 04, 2003 at 10:50:34AM -0800, sean.upton@uniontrib.com wrote:
Thinking aloud: ...so myNonZopeClass instances need to be a singleton-like thing, with some sort of mutex-ish of lock to prevent other instances from being constructed?
singletons seem to be more easily handled by other pythonic approaches, as you go on to say ...
I wonder if there is a way to throw an exception on construction of a myNonZopeClass instance if another Zope thread has an instance. Perhaps you could keep an external boolean lock variable in a module-level global accessible to all threads, but it might just be easier to follow Toby's suggestion and just see if you can keep your myNonZopeClass instance object in a module-level global, and just keep a reference to it in a _v_ attribute? I've never tried anything like this, might something like this possibly work?
I'd think so. Another approach to consider is "Borg" aka "Monostate" aka "all your state are belong to us". http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531 yet another approach is to use a class instead of a module, e.g. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/113657 None of these address the issues of access control, as Alex Martelli's comments on Borg make clear: """ threading, Alex Martelli, 2001/10/15 Threading issues really have little to do with Highlander vs Borg (or Singleton vs Monostate if you prefer boring names:-). In Python, it's simplest to devote a thread to handling a bunch of resources that need to be serialized (no matter whether they're wrapped into one or more objects of whatever type), with a Queue of requests on which the devoted-thread (Guardian thread) always sleeps working for requests. All access by working threads to the guardian thread and the resources it protects is by posting to the guardian queue a tuple (response-queue, callable, args, kwds) followed by waiting on the response-queue. Why people would want to conflate this important idiom with the equally important and unrelated idiom of state sharing is a mystery to me, as they work just as well together or separately. What's the contrary of "divide and conquer" -- "conflate and suffer"?-) """ hmmm, i can't quite envision how you'd do this "guardian thread" business in a Zope product, or if there's a better equivalent. -- Paul Winkler http://www.slinkp.com
On Tue, Mar 04, 2003 at 10:50:34AM -0800, sean.upton@uniontrib.com wrote:
instance. Perhaps you could keep an external boolean lock variable in a module-level global accessible to all threads, but it might just be easier to follow Toby's suggestion and just see if you can keep your myNonZopeClass instance object in a module-level global, and just keep a reference to it in a _v_ attribute? I've never tried anything like this, might something like this possibly work?
OK, I'll try to write something like this. The alternative is to open and close the device (serial ports in fact) every time, and rely on the system to disallow multiple opens at the same time (untested) Thanks to all. Jerome Alet
participants (3)
-
Jerome Alet -
Paul Winkler -
sean.upton＠uniontrib.com