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 _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers