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

[Barry Warsaw]

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
call.

Mailman 3 will make all this much more explicit.

-Barry