[ZPatterns] TransactionAgents: small bug in BoundaryAgents

[Steve Alexander]

I've just been doing lots of work with large amounts of data, 
subtransactions, dataskins, and _p_jar.cacheMinimize(3).

What I've found is that DataSkins really need to have their 
per-transaction _v_ attributes cleared on subtransaction commits as well 
as when the outer transaction commits. Otherwise, you can get a 
situation where _v_ attributes you thought would be around until the end 
of the transaction have actually disappeared.

This isn't an issue for standard-issue ZPatterns, because such 
attributes are cleared on subtransaction commits, as well as other 
transaction boundaries.

The patch to TransactionAgents is to change this:

   if not subtransaction:
       self.runBoundaryAgents() # ignores errors

to this:

   #if not subtransaction:
   self.runBoundaryAgents() # ignores errors

Find it at around line 70 of __init__.py, in the new_commit method.

I'll release a new TransactionAgents soon with this fix in it.


I'm using TransactionAgents with the modified ZPatterns on a fairly 
complex system. It works, and having IndexingAgents available as well as 
  RuleAgents has meant that I could get rid of some hacky subtransaction 
commits in my application code. The difference with having two kinds of 
agent is that the IndexingAgents for all DataSkins run after the 
RuleAgents for all DataSkins for a transaction. The equivalent case in 
standard ZPatterns is that you can only set the order of agents to run 
for a single Specialist.

Of course, Phillip Eby described this in the ZPatterns wiki months and 
months ago. I've only properly understood what it was all for now :-)

--
Steve Alexander
Software Engineer
Cat-Box limited