[Zope] More on understanding conflicts

[Dennis Allison]

Chris W,

The issue here has had to do with session variables and their iteraction
with the persistence mechanism and conflicts and multiple threads for the
same session.  Chris McDonough has pointed out that session variables can
cause writes and write conflicts even if the only Zope level access is a
read.  I thought MVCC works out of the box for Zope 2.8.4 which uses ZODB
2.3.4. Am I wrong?

The real surprise was that you can get a write conflict from a pair of
session variable reads!

Sorry, I wasn't all that clear when I had my epiphany about REQUEST and
transactions.  You said it much more clearly and precisely.  Since
conflict errors are discovered and managed when the publisher commits,
there is not a whole lot one can do, in terms of code organization, to
minimize the potential for conflicts.

Thanks for your insight.

On Wed, 21 Dec 2005, Chris Withers wrote:

> Dennis Allison wrote:
> > Ah so desu.  That's the conceptual hook I was missing.  Only one
> > transaction per request and no subtransactions!  
> 
> ZODB substransactions won't help you here in the slightest...
> 
> > A transaction is
> > processing initiated by a client request or a redirect. (Anything else?)  
> > A transaction has its own REQUEST and RESPONSE objects.
> 
> Wrong way round. Each REQUEST has one RESPONSE associated with it, and 
> the publisher does either a transaction commit, if no errors occur, or a 
> transaction abort, if errors occur, once it has processed a REQUEST. 
> Read conflict errors can be raised at any time, but shouldn't really 
> occur once you have MVCC working. Write conflict errors only happen 
> during transaction commit. The publisher retries the whole request if a 
> conflict errors of either sort occurs. If the retry fails 3 times, it 
> gives up, aborts the transaction and reports the conflict error to the 
> end user by way of writing to the response object.
> 
> hth,
> 
> Chris
> 
> 

--