[Mailman-Developers] (More) pristine archives

[Dale Newfield]

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