[ZODB-Dev] ZODB4 project plan

[Toby Dickenson]

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 probl=
em
> then it should be able to rollback to a consistent state (it may alread=
y
> have modified some objects in its substransaction).  It shouldn't be fo=
rced
> to care about other transactions it is also part of. =20

> 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 th=
is=20
year. Im not sure I would call them 'nested transactions' if they are not=
=20
durable.=20

> 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=20
describe as the outermost nested transaction. Does that make sense to you=
?