[ZODB-Dev] ZODB4 project plan

[holger krekel]

Phillip J. Eby wrote:
> At 09:33 PM 11/28/02 +0100, holger krekel wrote:
> >Phillip J. Eby wrote:
> > > At 06:41 PM 11/28/02 +0200, Pieter Nagel wrote:
> > >
> > > >I'd rather see nested transactions be the one and only transaction-like
> > > >concept embodied in ZODB.
> > >
> > > What do you use (or intend to use) nested transactions for?
> >
> >For composing several units of work where some of them
> >have alternatives when an error occurs.  I can then rollback
> >everything a certain unit of work modified and continue with
> >the alternative.  Only at the end of all the steps does the
> >outer transaction end.
> 
> Certainly, that's in principle all that nested transactions really 
> do.  Have you used Zope 2 subtransactions for this?  Did you find them 
> useful?  How many nesting levels do you need?

No, i haven't used Zope2 for this.  Some years back we prototyped 
a transactional system (in Corba/C++) from which xots.sourceforge.net emerged.
We used C++ templating to let objects access their current
(transactional) state parametrized by the current (thread) transactional
context.  So Subtransactions only took place in RAM.

I completly agree that DataManagers can be more complicated with nested 
transactions.  And i'd think that nested transactions needn't be 
supported by all Data managers.  

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. 

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?

regards,

    holger