[ZODB-Dev] ZODB4 project plan

[Phillip J. Eby]

At 11:49 AM 11/29/02 +0100, holger krekel wrote:

>Maybe it's just me but i like to move into a programming paradigm where i
>can write a "Component" which opens its own transaction regardless if it is
>part of a outer transaction or not.  This surely conflicts with using
>traditional XA-Adapaters. But then i don't think that transactions
>neccessarily should be tied with these types of persistence.

Quick question: couldn't you do this with a placeful transaction service?

In the work I'm doing with PEAK, there are times when a component needs a 
transaction for something, like sending a message to a sysadmin that 
something has failed.  But it doesn't want to use the current transaction, 
because that transaction is going to be aborted, which means the message 
wouldn't get sent.  So that component has a placeful transaction service 
that gives it another transaction to work in.


>An example. In a massive multiplayer universe i have lots of logics
>how the objects in this world interoperate.  Some components determine
>the outcome of local or wide-area fights, others implement 'research 
>development'
>and so on.  If the 'local fight' component detects a problem then it
>should be able to rollback to a consistent state (it may already have
>modified some objects in its substransaction).  It shouldn't be forced
>to care about other transactions it is also part of.  When and how to
>persist the game state seems like an (almost) orthogonal issue to me.
>
>For me the question of nested transactions boilds down to:
>should components be enabled to use transactional features regardless
>of their possible already transactional context?

It depends a lot on what you mean by "component".  Are you talking about 
Persistent objects?  In ZODB4, Persistent objects aren't in a 
"transactional context", their data manager is.  Data managers are 
responsible for keeping track of changed objects and committing or aborting 
them.