[Mailman-Developers] (More) pristine archives

[Barry A. Warsaw]

>>>>> "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