[ZODB-Dev] ZODB4 project plan

[Jeremy Hylton]

>>>>> "TD" == Toby Dickenson <tdickenson@geminidataloggers.com> writes:

  TD> 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?

  TD> That sounds like the rollback feature that Jeremy sketched out
  TD> earlier this year. Im not sure I would call them 'nested
  TD> transactions' if they are not durable.

I believe it is fairly typical that nested transactions and savepoints
are not durable.  A nested transaction doesn't actually commit until
it's parent transaction commits, so durability doesn't seem to be an
issue.  

There are some esoteric notions like persistent savepoints and phoenix
transactions (a recoverable subtransaction that rises from the ashes
of a crash), but I don't believe they are widely used.

Jeremy