[ZODB-Dev] ZODB4 project plan

[holger krekel]

Toby Dickenson wrote:
> On Friday 29 November 2002 10:49 am, holger krekel wrote:
> 
> > 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.  
> 
> > 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?
> 
> That sounds like the rollback feature that Jeremy sketched out earlier this 
> year. Im not sure I would call them 'nested transactions' if they are not 
> durable. 

IMO this depends whether you tie transactions and persistence.  I know
that the D in ACID means durable but i'd dare to say that 'durable'
doesn't neccessarily mean transfering state to persistent storage.  

> > When and how to
> > persist the game state seems like an (almost) orthogonal issue to me.
> 
> I think Jeremys proposed scheme would have persistence occur at what you would 
> describe as the outermost nested transaction. Does that make sense to you?

Yes, it makes some sense.  Do you have a pointer? 

Though the transactions i like to have are somewhat different from 
transactions which help persisting state.  The latter usually have 
to deal with XA/Data managers and thus with security/users etc. 
while the former just need to assist managing states in RAM.   
But tying a 2PC protocol (storage transactions) to the outermost 
application transaction often does make sense.

I really should implement a nested "application" transactions
module in python and use it in practice to see how it fits in. 
Ignoring any XA/Data manager stuff this should be implementable 
pretty easily.  At least orders of magnitudes easier than doing
it with C++ templates :-)  

regards,

    holger