On Thu, 29 Aug 2002, Barry A. Warsaw wrote:
DN> Wouldn't that abort be triggered by a call to .UnLock() DN> without a call to .Save()? I would think that all calls to DN> .Lock() and any calls to .UnLock() without a prior call to DN> .Save() should abort any current transaction.
What about the qrunners that don't lock the list because they only need read access to the data? That's why I think we need an explicit abort, even if it's no-op'd for the old-style persistence.
If it's read-only, I don't see the problem unless you need the data it is reading to remain unchanged (locked) for some span of time. Transactions are only related to changes made to the database. A read-only MailList would always be able to read, and at any given point in time the information returned would be that most recently committed. (I.E., If one process is reading and another modifying, the reading process will see the data from before the modifications until the writing process commits, then the reading process would see *all* those mods (no need to worry about incomplete changes--that's the point of an all-or-nothing transaction).)
Ah, so the problem probably isn't the transaction boundaries, but that Mailman assumes that each list's persistence is completely independent of other lists.
Right.
I think the one place where you'll get hosed by this is in the cgi's where "global" operations loop through all the lists (yes, this sucks and is inefficient, but its the best we can currently do).
I was hoping that these loops were always read-only, or that they could be serialized so that only one MailList is ever locked at a time.
I'm not sure how to get around this, except through some kind of elaborate nested transaction support.
Which is a road we really don't want to go down--Even if some random SQL implementation supported that, SQL doesn't support it in the standard.
Hmm. I'm going to have to think about this some more. I'm off line right now so can't look at code details.
OK. I'm going to go ahead and continue my development hoping that there's no show-stopper here. We do need to continue this conversation, but I also want to actually get stuff working :-)
-Dale