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 _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
