Hi Steve,

ZPatterns is something that is very high on my must investigate list, 
but I am not doing Zope development, but rather ZODB based development.

I'm sure that I can still get lots of good ideas though...

My comment below about _v_* attributes is primarily about not using 
functionality like Keeper or TM, but rather just taking advantage of 
_v_* attributes for caching purposes.

What I would want from caching, volatile variables is to reset only when 
the object, or more safely the session, has conflicted and needs to be 

I wouldn't want to take the performance hit for the cases where I have 
only successful commits on the same Connection cache of objects.  In 
that case I would needlessly be reseting my volatile cache.

In our code we are overriding _p_deactivate() like this:
def __p_deactivate__(self):
temp = _v_something

We are only doing this for instance vars that are not sensitive to 
commit/abort cycles.

I think that the ideal situation would allow the volative cache to be 
reset only in the case of a Conflict, i.e. abort()

There are two scopes that this can happen at:
1) The _v_* vars that are only local to the Persistent object that they 
are defined within.

This would be a __p_reset__() method or something that is called by the 
ZODB Connection mechanism.

2) Session wide, i.e. _v_* vars that are dependent on multi-object state 
but happen to be stored on one of the Persistent objects.

This would be handled by Keeper or TM like solutions.

Anyway, this is just my current mental state dump.  ;-)


Steve Alexander wrote:

> John D. Heintz wrote:
>> Hi Tim,
>> I have two suggestions, I hope one of them helps.
>> 1) Attached is a TM.py file that I wrote based on the one you mention 
>> below.  I've tried to make it more obvious and better documented.
>> 2) Don't use this kind of functionality, but rather use 
>> sub-transaction commits.
>> The first suggestion has more overhead than what I assume you would 
>> need, but the second one won't work for all situations.
>> A Fishbowl proposal of mine, HashingSupport, was going to use the same 
>> kind of hook you are asking about.  In this case though, using 
>> sub-transaction commits made a lot more sense.
>> In general though, I think that _v_* attributes pose a non-trivial 
>> problem that probably requires a hook on abort() if not commit() as well.
> Take a look at ZPatterns; specifically, the classes Keeper and Kept from 
> ZPatterns/Transactions.py
> You can see examples of how they are used in DataSkins.py and Rack.py, 
> although there really isn't much to it.
> I've included the docstrings below.
> class Keeper:
> """Resets an object's per-transaction cache attributes at txn boundaries
>    Note that Keepers are created by Kept objects semi-automatically, 
> and   there is usually no need to create one manually.  A Keeper
>    automatically registers itself with the Zope transaction upon
>    creation, and instructs its Kept client to clear its per-transaction
>    cache at all transaction boundaries.  Keeper methods are called only
>    by the Zope transaction, so don't mess with them."""
> class Kept(Base):
>     """Thing which has a Keeper to clear its per-transaction cache.
>     Objects derived from Kept should reference the 'self._v_Keeper'
>     attribute whenever they need to flag that they have made changes to
>     their cache that would require it to be cleared.  (Note that
>     '_v_Keeper' is an *attribute*, not a method, and so should not be
>     called, just referenced.)
>     Once this has been done, the next transaction state transition
>     that occurs (sub/main transaction commit or abort) will cause
>     the object's Keeper to call for a cache reset.
>     Subclasses of Kept should define a '__per_transaction_cache_attrs__'
>     attribute as a sequence of attributes which they would like to have
>     deleted from their '__dict__' at reset time.
>     """

. . . . . . . . . . . . . . . . . . . . . . . .

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]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to