[ZODB-Dev] ZODB4 project plan

[Phillip J. Eby]

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?

If you could describe an application example it would be most helpful.  I 
want to ensure that PEAK's transaction handling stays reasonably compatible 
with Zope 3's transaction handling and whatever ends up as the "official" 
Python transaction API.

I have had at least one situation where it seemed like it would be a good 
idea in an application to do as you describe; but I found it easier in 
practice to simply redisplay the un-committed data, prompt the user to fix 
the problems, and then resubmit the entire batch of data.

Perhaps you could describe a specific scenario in more detail?  My concern 
is that a correct implementation of nested transactions is likely to be as 
"twisty" in some ways as the current versions code, if not more so.

Worse, implementing nested transactions imposes an extra burden on the 
developers of data manager objects!  PostgreSQL, for example, doesn't do 
nested transactions.  So, if any one data manager used in your transaction 
doesn't support nesting, you might as well not have nesting.

That's why I'm curious about things such as what specific application you 
had in mind, along with what kind of back-end data store, etc., and whether 
you've actually used nested transactions in an app yet, e.g. Zope 2 
subtransactions which supply one nesting level.