[Zope-dev] Session Errors (read conflicts)

[Toby Dickenson]

On Tuesday 18 March 2003 3:24 pm, Chris McDonough wrote:

> > Our live sessions code uses the sessions about half to two-thirds of the
> > way through the transaction. Given what can happen in that first half,
> > there is easily plenty of time for read conflicts. I think I might be
> > able to move our session use to the beginning of the transaction (just
> > storing stuff in the REQUEST object for later usage) and hopefully fix
> > our issue.

Depending on what your sessioning involves, you might not need to change when 
you do all the "work". Possibly just touching (an attribute of) the 
persistent session object will be enough.

> But I'm not sure I understand why touching an object at the start of a
> transaction would fix the consistency problem.  If a object A is read at
> the beginning of a transaction that uses the data from object A during
> write of object B and later object A changes and is invalidated by
> another transaction (before the first finishes), no conflict errors will
> be raised.  Isn't there the potential for the first transaction to write
> inconsistent data into object B?

Today you are guaranteed that your transaction reads a consistent initial 
state of A and B. That is, there is no chance that you only see half the 
changes of a recent transaction that modified both.

Yes, it is possible for one transaction to modify A and a concurrent 
transaction to modify B. This is what Deiter describes as "not safe" in that 
zodb-dev thread. IMO, it is only not safe if you are not aware of it. And it 
is critical for performance with concurrency - consider these two 
transactions occuring on different zeo nodes.

>  In my mind, this is the same thing as
> using a "low conflict connection" (ie. you are essentially "turning off"
> read conflicts, albeit by circumstance rather than by code).

There is a significant difference. The low conflict connection permits the 
possibility of seeing half the changes of a recent transaction that modified 
both objects.

"low conflict connection" is a misleadnig name. The conflicts are still there 
- just not reported as exceptions. "low consistency connection" would be more 
accurate ;-)