Re: [Zope-dev] Re: ComputedAttribute
Chris Withers writes:
Martijn Pieters wrote: Now I think I know the answer to this one, but I'll ask just to be sure:
class MyClass(Persistent Acquisition.Explicit):
def _set_your_attribute (self,value): self._v_your_attribute = value
def _get_your_attribute (self): return self._v_your_attribute
your_attribute = ComputedAttribute(_get_your_attribute)
....with this class, your_attribute isn't going to play in Persistence, is it? (so I can update it lots without worrying about ZODB size growing... :-) But, as I understand it, it is only updated in the thread that did the update. Your next request may get a different thread and see a different value.
Dieter
Chris Withers writes:
....with this class, your_attribute isn't going to play in Persistence, is it? (so I can update it lots without worrying about ZODB size growing... :-)
But, as I understand it, it is only updated in the thread that did the update. Your next request may get a different thread and see a different value.
Huh? If I change self._v_your_attribute it's only going to get updated in one thread? That's a bit sucky :-S Doesn't matter in this _particular_ case 'cos this var gets set at the start of every request, but I'm a bit concerned about its general use... any help is good help :-) Chris
On Wed, Jan 10, 2001 at 11:37:55PM -0000, Chris Withers wrote:
Chris Withers writes:
....with this class, your_attribute isn't going to play in Persistence, is it? (so I can update it lots without worrying about ZODB size growing... :-)
But, as I understand it, it is only updated in the thread that did the update. Your next request may get a different thread and see a different value.
Huh?
If I change self._v_your_attribute it's only going to get updated in one thread? That's a bit sucky :-S
Doesn't matter in this _particular_ case 'cos this var gets set at the start of every request, but I'm a bit concerned about its general use...
any help is good help :-)
The whole threading spiel in Zope works because of ZODB persistence; any thread accessing an object whose variables have been changed has to retry with a fresh copy from the ODB. But because _v_* variables don't get pickled, another thread will never see them. If you want non-persisting (volatile) variables shared between threads, you'll have to devise your own mechanism for assuring the thread-safety of those variables. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
Martijn Pieters wrote:
But because _v_* variables don't get pickled, another thread will never see them. If you want non-persisting (volatile) variables shared between threads, you'll have to devise your own mechanism for assuring the thread-safety of those variables.
Or, instead of devising your own mechanism, you can borrow someone else's: http://www.handshake.de/~dieter/pyprojects/zope/SharedResource.html Thanks Dieter! -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
On Wed, Jan 10, 2001 at 11:09:43PM +0100, Dieter Maurer wrote:
Chris Withers writes:
Now I think I know the answer to this one, but I'll ask just to be sure:
class MyClass(Persistent Acquisition.Explicit):
def _set_your_attribute (self,value): self._v_your_attribute = value
def _get_your_attribute (self): return self._v_your_attribute
your_attribute = ComputedAttribute(_get_your_attribute)
....with this class, your_attribute isn't going to play in Persistence, is it? (so I can update it lots without worrying about ZODB size growing... :-) But, as I understand it, it is only updated in the thread that did the update. Your next request may get a different thread and see a different value.
Indeed, only persistent variables are shared between threads (and globals of course, which creates a need for some kind of protection). -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
participants (4)
-
Chris Withers -
Dieter Maurer -
Martijn Pieters -
Steve Alexander