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