Re: [Zope-dev] How would I keep _v_* attributes from getting thrown away?
Thanks for the warning Dieter, but I'm managing threads/connections/sessions/POAs and a few other things already to expose ZODB objects through CORBA sessions. I wanted the _v_* attributes to live for the life of the DB Connections. Last night I found a fix for the bug that prevented me from overriding the _p_deactivate() method on Persistent objects, so I think that I will just do this: class ... def _p_deactivate(self): temp_position = self._v_position Persistent._p_deactivate(self) self._v_position = temp_position Thanks for the help though. John Dieter Maurer wrote: > John D. Heintz writes: > > I am using ZODB along with CORBA to expose peristent objects. Some of > > my objects have per-connection/session state. > > ... > > My initial idea is to have a _v_position attribute ... > Using "_v_" attributes for session state is a very bad idea. > They are thread(!) local and not session local. > This means, if a following request of your user (in the same session) > happens to get assigned a different thread, it will read > and update a different position. Chaos is garanteed (though you > will see it only, if your site is loaded). > > Use a session product (-> zope.org) for session data. > > > Dieter > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How would I keep _v_* attributes from getting thrown away?
John D. Heintz writes: > I am using ZODB along with CORBA to expose peristent objects. Some of > my objects have per-connection/session state. > ... > My initial idea is to have a _v_position attribute ... Using "_v_" attributes for session state is a very bad idea. They are thread(!) local and not session local. This means, if a following request of your user (in the same session) happens to get assigned a different thread, it will read and update a different position. Chaos is garanteed (though you will see it only, if your site is loaded). Use a session product (-> zope.org) for session data. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] How would I keep _v_* attributes from getting thrown away?
Hello all, I am using ZODB along with CORBA to expose peristent objects. Some of my objects have per-connection/session state. The clear example is file-like objects - effectively exposing persistent StringIO objects through CORBA. The issue is that I want multiple clients to be able to read() iterate over the same file-like corba objects. My initial idea is to have a _v_position attribute that is unique for each Connection cache object and maintains the correct position in the StringIO for each session. I obviously wouldn't want this to be a persistent attribute because a spurious commit would put it into the db and mess up any other users iterating through the same object from a different session. A volatile attribute, _v_position, however can be destroyed at any time with a cache cleanup via deactivate() call. How do I maintain volatile, but per connection stable, attributes on persistent objects? I thought about overriding the _p_deactivate() method, but I am also defining the __call_method__() hook and am bound by Bug 1783 that prevents this kind of thing. My thoughts on building this into cPersistent.c after looking through the code is to provide special processing to not remove some special attributes that also don't get saved into the db. Two ideas come to mind for this: 1) define _vs_* as volatile stable that is neither persisted nor clear()ed. This would slow down the deactivate() method though. 2) define _v_stable as a special volatile that doesn't go away. This would be quick processing in deactivate() and could be a dictionary to account for many stable volatile attributes. Thanks for any help, John -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
