[ZODB-Dev] savepoint bug

[Tim Peters]

[Edward Moy tries out his savepoint patch, and finds mysterious
 behavior; Jeremy Hylton cogitates, and finds savepoint bugs by
 raw brain power, but isn't sure they're the cause of Edward's
 problems
]

FYI:  savepoints didn't make it into 3.3b1, and since the feature set was
frozen with the first beta, won't be in 3.3 final either.

Jim and I were looking for places to simplify ZODB code today, and wondered
whether implementing real savepoints might allow substantial reduction in
the distributed, confusing mass of current special-casing for the feebler
"subtransactions".  I think they would, but since we don't know for sure yet
we're doing exploratory work on a branch (ZODB/branches/tim-transactions).

Jim concocted problem scenarios that I think were akin to Edward's, and also
raised nasty questions about what happens if resource managers join a
transaction at various times between savepoint creations.  We're playing
with an implementation on the branch that looks like it should solve these
problems.  A linked sequence of currently-active savepoints is maintained,
and rollback works by paying attention to all savepoints in the sequence,
from the most recent back to the target savepoint.  This means the work
involved in a rollback will be proportional to the number of still-active
savepoints created after the rollback savepoint; in return, the rollback
machinery can know about every change made at and after the rollback target.

This is a novel approach, trying to do something obviously correct instead
of something so clever it's not obviously wrong <wink>.  BTW, note the
change in terminology:  these are SavePoint objects now, not Rollback
objects.  They have a rollback() method, though.

I have high hopes that this will work out for ZODB 3.4, but no promises at
this time.