[ZODB-Dev] Pluggable transactions logic

[Steve Alexander]

John D.Heintz wrote:
>
> I would expose more detail that just "boundary".  The ZODB Transaction 
> spilts  that into tpc_vote() and tpc_finish() calls.  The primariy 
> difference between
> these is that tpc_vote() can raise an Exception and abort the whole 
> Transaction while tpc_finish() gets ignored.

I think the contract says that you must not raise an exception in 
tpc_finish. I think doing so gets you a hosed ZODB.


I don't see a need to go into this much detail. You can just register an 
object with the transaction to get these messages.

But, perhaps you have a need to do something just before or after the 
transaction enters the vote or finish phases? I think I should look more 
closely at your ZCF.


>>Those are the ones motivited by the use-cases I have so far. There may
>>eventually be others.
> 
> I think that the distinction between vote and finish is important for 
> integrating external transaction systems with processing during a ZODB 
> Transaction.commit().  We are doing this (and using vote() time 
> processing
> not finish()) to store the content of some object on the file system 
> instead of in the ZODB Storage.

ZPatterns has done the same thing, but in commit rather than vote.

TransactionAgents does all this right at the start of the commit() 
method of Transaction. This is good if you expect agents to either add 
other agents, or commit subtransactions.

Do you need to do your thing at vote time?

Perhaps you can take a look at TransactionAgents and see how much of it 
is similar in intent to your transaction tools.

> but I is different that coding a
> registerBeforeTransactionCommit() callback which I would assume would > be run before *any* other ZODB code.

Yes, you're right. Take a look at when Indexing Agents and Rule Agents 
get called in TransactionAgents.


>>I imagine the NORMAL to represent some arbitrary priority, say 100.
>>There should be constants for NORMAL, FIRST_PLEASE, and WHENEVER.
>>
> 
> In my vision the priorities would all be handled by the "Agent" manger 
> class
> that used Transaction callback registrations to dig into the 
> Transaction
> commit() process at the various points: begin, vote, finish, abort, 
> and 
> postCommit. [Note: the first four are already built into the ZODB 
> infrastructure.  I have included the last one because we needed it and > it  follows pretty closely.]

While you can hook into these points, I can see the need to say "I want 
my vote method to run before any vote methods of normal _p_jars", and 
that kind of thing. This is why I'm thinking of a system that works at a 
slightly lower level than the messages an object gets when it has 
registered with a transaction.

The point of the Boundary call-backs is to allow for things like 
strictly-per-transaction cached variables. ZPatterns uses these a lot.

You could think of Boundary call-backs being the union of Commit and 
Abort call-backs.

> We definitely need to have this defined lower that Zope.  

Absolutely. I too use the ZODB on its own.

I was thinking of the Zope Management Interface because I can see an 
end-user installing a couple of different transaction-processing 
add-ons, and then wanting to clearly see what is being plugged in where, 
and also, in the role of integrator, to be able to say what has priority 
over what. I see the Zope interface being built upon a simpler ZODB API 
of some sort. Perhaps that is what your Agent manager classes do?

I suppose the difference might be that I'm thinking of an ZPI where you 
can declaratively mediate between different transaction plug-ins, which 
may not know about each other.


<< automatic cataloging>>
> Hmmm.  This is interesting - and definitely a different topic than 
> I've been
> thinking about.  I think the way I would have guessed this to be 
> handled was 
> whatever method handled uncatalog would create (probably indirectly) a 
> CommitActivity that handled the logistics of doing/undoing the 
> necessary
> catalog manipulations.  This probably isn't what you were thinking is 
> it?

I'm not sure I follow.

I think what Chris was talking about was asking the Transaction 
machinery to perform certain actions (such as cataloging and 
uncataloging) whenever objects of a given class change state.

This might work for cataloging changes of persistent state, but it won't 
work as described for uncataloging an object when it gets deleted, as 
nothing actually happens to an object's persistent state when it gets 
deleted.

There is a hook, if the object is an Item or does CopySupport or some 
such thing. But, that's just a method call, and not a change of 
persistent state.

--
Steve Alexander
Software Engineer
Cat-Box limited