[Zope-dev] How would I keep _v_* attributes from getting thrown away?
John D. Heintz
jheintz@isogen.com
Fri, 19 Jan 2001 15:40:27 -0600
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 | jheintz@isogen.com
w w w . d a t a c h a n n e l . c o m