[ZODB-Dev] Pluggable transactions logic
Steve Alexander
steve@cat-box.net
Mon, 30 Jul 2001 20:27:21 +0100
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