Dale, et al,

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

...does your code basically change the semantics so that effectively a "save" happens after every single state change, yet the "save" method is a no-op?

All I've done is implemented the Mailman 2.1 MemberAdaptor API as-is against a MySQL (which, incidently doesn't support transactions by default, unless they've started making InnoDB tables the default type) backend, without changing the semantics of anything(AFAIK), the only changes of any import that I've made are that the Member data structures are stored in a way that fits MySQL and converted as they are loaded to the way that fits Mailman, which you'd expect...

It saves when a save method is called, loads when a load method is called, but that API doesn't include a lock and unlock method, so I've not implemented one (although I've left calls to 'self.__mlist.Locked()' in the code where they're appropriate, ie. where they are in OldStyleMemberships.py too).

If there are changes being made to the data internally to the rest of Mailman that don't make calls to the MemberAdaptor API, then they are unaffected by my additions, and consequently they won't be having any effect on the MySQL database.

However, having thought about it, you're probably talking about changes to the base structure of the list (name, footer, header, all that stuff), which isn't covered by the MemberAdaptor API, and hence I've not touched on.

If an API for that purpose were provided (which AFAIK is pending, but not there yet, except maybe in CVS?), then I'd write the code for a MySQL backend, but I don't think I could, or should play about with the internals of Mailman beyond that. I just don't understand either Python or Mailman enough at that sort of level to do so, and I certainly don't want to introduce any obscure and nasty bugs into the core code...

Please do correct me if I'm wrong on any of this?

K.

-- Kev Green, aka Kyrian. "Be excellent to each other" -- Bill & Ted. Email: kyrian@ore.org Web: http://kyrian.ore.org/ ISP/Perl/PHP/Linux/Security Contractor, via http://www.orenet.co.uk/

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