[ZPatterns] TransactionAgents: explanation

[Steve Alexander]

Steve Spicklemire wrote:
 >
 > It would help me a lot if you could describe your application a
 > bit,
 > and why it needs TransactionAgents (i.e., elaborate on what
 > TransactionAgents allow you to do, or not do, in your application that
 > would be impossible/difficult with stock ZPatterns.)


Ok.

The first thing is that I want to be able to commit subtransactions from
within code run from triggers.

You can't do this with stock ZPatterns, and as Joachim Schmitz found
out, this can cause problems if you leave subtransactions enabled in
ZCatalog while updating a lot of DataSkins that recatalog themselves.

(Actually, I think one of the contributing factors to this is fixed in a
very recent Zope. However, this would just make the error happen less
often, rather than making it work correctly.)

There are other things that use subtransactions, such as uploading files
and images into Zope.


The second thing is that I want indexing to work after rules, without my
having to worry about exactly what the rules code is doing.

At the moment, within a single specialist, you can making indexing work
after rules by putting the SkinScript methods (or other agents) in the
order that they should run. However, this only preserves that order
within a single specialist. What I want is for all specialists involved
in a transaction, all their indexing agents that ought to run will run
after any other agents.


The problems I've had go like this:

   object A changes
   object B changes
   object A gets indexed
   object B's trigger makes a change in object A
   object B get indexed

So, we get an incorrect version of object A in the index.

What I want is:

   object A changes
   object B changes
   object B's trigger makes a change in object A
   objects A and B get indexed

As indexing agents always run after all the rule agents for a 
transaction have run, this works, and makes things much easier. Reduced 
coupling between indexing logic and rules logic.


With TransactionAgents, I can also have rule agents add indexing agents. 
Again, this is useful if you want to do something with the final state 
of the objects, within the transaction. Perhaps you want to copy the 
state of an object to an RDB.


The other things I'm using transaction agents for a to clear RAM Caches 
after certain changes have been completely commited. I'm using a 
PostCommitAgent for that. This is similar to one of the things John 
Heintz needed for his CORBA work, except that I commit a transaction 
after the PostCommit agents run. John doesn't need to because each of 
the actions performed by a post-commit agent commits its own transaction.

--
Steve Alexander
Software Engineer
Cat-Box limited