[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