[ZODB-Dev] Pluggable transactions logic

[Steve Alexander]

Chris Withers wrote:
>  I was anticipating
> whatever initialises and commits transactions would keep a list of the
> registered agents (to use my words) and call the appropriate ones, in 
> order, atthe appropriate points.
> 
> Would that be possible?
> 
> Would it be a good idea?


What I've sketched out on paper goes something like this:

Products can register that they want to be notified at various points in 
transaction processing.

These points are:

   register      to be notified when an object registers itself with the
                 transactions machinery

   pre-commit    this is where indexing agents and rule agents run

   boundary      when a transaction gets commited or aborted

   post-commit   after a transaction is finished

and possibly

   abort         when a transaction aborts


Those are the ones motivited by the use-cases I have so far. There may 
eventually be others.

A plug-in will register with the ZODB something like this:


from ZODB.Transaction import registerPlugIn, PRECOMMIT, NORMAL

registerPlugIn(myMethod, "TransactionAgents indexing and rule agents", 
PRECOMMIT, NORMAL)


This says that myMethod will be called every time a transaction is about 
to start the TPC process.

I imagine the NORMAL to represent some arbitrary priority, say 100. 
There should be constants for NORMAL, FIRST_PLEASE, and WHENEVER.

I have this image of an add-in to the Zope control panel where you can 
interactively jig around with the ordering of the plug-ins. That's what 
the second descriptive argument of registerPlugIn is. So, the priority 
is kind of advisory. There is an API for application writers to alter 
the order in the ZODB, and a ZMI tool for this when used in Zope.


In the current version of TransactionAgents, I've added methods to the 
ZODB Transaction class to register various kinds of agents. I see these 
moving into the a module in the TransactionAgents product, for people to 
import as necessary.

----

Note to Chris:

In your use-case, how do you see your objects uncataloging themselves?
When an object gets deleted, it is its parent that gets registered with 
the transaction, not the object. This is because the parent just severs 
the link to the child, and the garbage collector sees to the rest.

I still think you end up with something like ZPatterns' DataSkin class 
to allow an object to know when it has been changed, and how, and 
whether it is being added, deleted or renamed.

--
Steve Alexander
Software Engineer
Cat-Box limited