[Mailman-Developers] (More) pristine archives

[Dale Newfield]

On Thu, 29 Aug 2002, Barry A. Warsaw wrote:
> The intent is that .Save() markes the transaction boundary and is
> equivalent to a transaction commit.

Right.

> Thus, if the code in the try causes an exception, the list will still
> get unlocked (otherwise the list would be hosed), but the transaction is
> aborted by virtue of not getting saved.  A subsequent load of the mlist
> would begin a new transaction, with the old data.

Right, but since .UnLock doesn't reload the data, any code refering to
that mlist after unlocking would have different semantics depending upon
which MemberAdaptor implementation is backing the list:  With OldStyle,
membership data in that mlist object is whatever it's been (temporarily)
set to (but not saved); with SQL, membership data in that mlist has
reverted to whatever it was when .Lock() was called.

> It's this last bit that's dodgy.  There should probably be an explicit
> abort on exceptions inside the try, but there's no way to spell that
> with the current, legacy persistence mechanism, so it isn't in any of
> the code.

Wouldn't that abort be triggered by a call to .UnLock() without a call to
.Save()?  I would think that all calls to .Lock() and any calls to
.UnLock() without a prior call to .Save() should abort any current
transaction.

> I /think/ that if your MailList.Load() implicitly aborts any active
> transaction, you should be okay, but of course, none of that's tested.

MailList.Load() or MailList.Lock()?
Having .Load() abort any active transaction means that you cannot load
other mlists (even read-only) inside a .Lock();try....Save();finally
.UnLock() block and have the transaction succeed...

The place these two models (SQL transactions and mailList load,
lock/save/unlock) break down is what happens when there are more than one
MailList object in memory at a time.  SQL transactions assumes only one
MailList can be modified at a time, and the lock/save/unlock model doesn't
make that assumption.

If we can assume that only one mlist gets locked at a time, the SQL system
will work, but I see no way to enforce mailman developers to abide by that
assumption.  (Except to implicitly abort active transactions as described
above--and since the MailList.Save() method doesn't have a success/failure
return code, there would be no indication that anything went wrong except
silently ignoring requested DB changes.)

-Dale