"DN" == Dale Newfield <Dale@Newfield.org> writes:
DN> I'm still concerned about having all of the operations in the
DN> lifetime of a mailman session reside in a single (possibly
DN> never confirmed) transaction, and whether that provides the
DN> interface we want (I.E., set values not actually getting set
DN> until .Save() time).The intent is that .Save() markes the transaction boundary and is equivalent to a transaction commit. The qrunners are careful to only lock the lists when they need to modify list attributes, and they're always save the list inside the try clause, but unlock the list in the finally clause, e.g.:
mlist.Lock()
try:
# do some stuff to mlist's attributes
mlist.Save()
finally:
mlist.Unlock()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.
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. I /think/ that if your MailList.Load() implicitly aborts any active transaction, you should be okay, but of course, none of that's tested.
-Barry