[Mailman-Developers] (More) pristine archives

[Barry A. Warsaw]

>>>>> "DN" == Dale Newfield <Dale@newfield.org> writes:

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

    DN> If it's read-only, I don't see the problem unless you need the
    DN> data it is reading to remain unchanged (locked) for some span
    DN> of time.

No, I was just thinking about read consistency here.  I think you
basically want the read state frozen at the start of the _dispose()
method, which will either start with a Load() or a Lock().  It might
be a bad thing (unless it isn't <wink>) for the state to change during
_dispose(), even if the list is only reading its data.
    
    DN> Transactions are only related to changes made to the database.
    DN> A read-only MailList would always be able to read, and at any
    DN> given point in time the information returned would be that
    DN> most recently committed.  (I.E., If one process is reading and
    DN> another modifying, the reading process will see the data from
    DN> before the modifications until the writing process commits,
    DN> then the reading process would see *all* those mods (no need
    DN> to worry about incomplete changes--that's the point of an
    DN> all-or-nothing transaction).)

Part of the point is also to provide consistent state for read-only
data.  In ZODB for example, it's possible to get read-conflicts if the
state of the objects aren't consistent.  E.g. you read obj1 from
transaction1, which has a reference to obj2.  Before you read obj2,
process2 has modified obj2 in transaction2.  Now process1 reads obj2.
Inconsistent state and a read-conflict occurs.  (Aside: ZODB4 will
likely have multiversion consistency control which assures that
process1 will read obj2's state as it existed in transaction1).

This works in Mailman by doing a Load/Lock at the top of _dispose to
sync the in-memory state with the on-disk state for the duration of
the method.

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

    DN> I was hoping that these loops were always read-only, or that
    DN> they could be serialized so that only one MailList is ever
    DN> locked at a time.

I believe they're serialized (they do write state), /except/ for the
"parent" list for the process.  E.g. I visit list1 to change my
password, but click on "set globally".  list1 remains locked while I
cycle through the other lists, locking them in turn and making those
changes.

We may have to rewrite a few of these loops.

    >> I'm not sure how to get around this, except through some kind
    >> of elaborate nested transaction support.

    DN> Which is a road we really don't want to go down--Even if some
    DN> random SQL implementation supported that, SQL doesn't support
    DN> it in the standard.

Ok.

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

    DN> OK.  I'm going to go ahead and continue my development hoping
    DN> that there's no show-stopper here.  We do need to continue
    DN> this conversation, but I also want to actually get stuff
    DN> working :-)

+1 :)

Let us know how it goes.
-Barry