[Mailman-Developers] Mysql MemberAdaptor Load/Save/Lock/Unlock

Barry Warsaw barry at python.org
Mon Nov 10 11:47:35 EST 2003

On Mon, 2003-11-10 at 07:14, Dale Newfield wrote:
> I don't think I understand how you reconcile Mailman's load/save
> transaction units with sql's transaction.
> There are places in mailman where a list is loaded and manipulated, but
> not saved...

That's not supposed to happen.  Yes, the list will be loaded and
attributes read, but not saving the list after mutations would simply
throw the changes away, which isn't good.  That'd happen with the
existing OldStyleMemberAdaptor just the same.

Mailman's CGI interface are wrapped in a common pattern such as:

- lock (or load) mlist
- try
-   do some stuff
-   save
- finally
-   unlock

The runners have a similar pattern.  The lock/load is equivalent to a
transaction begin, the save is equivalent to a transaction commit, and
the unlock is equivalent to a transaction abort -- assuming that an
abort after a commit is safe for the underlying database (as it is e.g.
for ZODB).

Thus, if an exception occurs in the try block, you'll never get to the
save and the current set of changes will simply be aborted at the unlock

Mailman 3 will make all this much more explicit.


More information about the Mailman-Developers mailing list