[ZODB-Dev] future of nested transactions

[Edward Moy]

On Apr 19, 2004, at 9:55 AM, Kapil Thangavelu wrote:

> On Mon, 2004-04-19 at 12:15, Edward Moy wrote:
>> On Apr 18, 2004, at 7:02 PM, Jeremy Hylton wrote:
>>
>>> On Sun, 2004-04-18 at 21:00, emoy at apple.com wrote:
>>>> I recent sent a message out about ZODB4 and savepoints, not knowing
>>>> until now that ZODB4 has been halted indefinitely.  Since I need
>>>> support for multiple nested transactions, does anyone know what the
>>>> immediate plans are for this in ZODB3, if there are any.
>>>>
>>>> ReviseTransactionAPI seems to indicate that a new transaction API is
>>>> not necessary for 3.3.  But I need something fairly soon, or else I
>>>> may
>>>> have to look elsewhere for an appropriate solution.
>>>
>>> It will probably take some volunteer time to get savepoints  
>>> integrated
>>> into ZODB 3.3.  It should be pretty straightforward, in principle,
>>> because the code just needs to be adapted from ZODB 4.  In practice,
>>> the
>>> ZODB 3 and ZODB 4 internals are different enough that it's a
>>> non-trivial
>>> effort to integrate the code, write new tests, and make sure existing
>>> tests don't break.
>>>
>>> Several people have expressed an interest in seeing the savepoints  
>>> get
>>> into 3.3 -- and they would really simplify the implementation and the
>>> user-visible interface.  Perhaps the interested parties could all  
>>> pitch
>>> in.
>>
>> OK, I'm willing, if it doesn't take too long.  My first question is,
>> how best do I come up to speed on the internals to be able to do this?
>> Then given my first posting to this list, what changes are needed to
>> fix the arguably broken behavior of ZODB4's savepoints so that 3.3  
>> will
>> work more intuitively?
>
> could you describe what you think is intuitive behavior for this?

As mentioned in test_txn.py in ZODB4:

         # XXX Should change savepoint() so that you restore to the state
         # at the savepoint() not at the last txn activity before the
         # savepoint().

A simple example of ZODB4's non-intuitive behavior is that if you open  
your database, call savepoint() immediately, make some changes and then  
call rollback(), this will apparently not rollback any changes.   
Likewise, if you open your database, call savepoint(), make some  
changes, call savepoint a second time, and immediately rollback the  
second savepoint(), you will rollback to the first savepoint(), to the  
initial unmodified state.  Finally, if in the second example you call  
savepoint() a third time immediately after the second savepoint(),  
rolling back this third one still gets you back to the first  
savepoint() state, not the second.

It makes more sense that when I call savepoint(), it should save the  
state at that exact point, not some less determinate state at some  
point before I called savepoint().

------------------------------------------------------------------------ 
--
Edward Moy
Apple

(This message is from me as a reader of this list, and not a statement
from Apple.)