zope.session SessionData generates unnecessary ConflictErrors

[Gary Poster]

The use of zope.minmax.Maximum in zope.session.session.SessionData was supposed to eliminate the most common ConflictError hotspot for sessions. For backwards compatibility, the Maximum object (on the _lastAccessTime attribute) is accessed via a property on SessionData.

Unfortunately, setting a property, even if it then delegates to another Persistent object, triggers the Persistent __setattr__ hook. Therefore, SessionData gets an _p_changed = True, even though nothing has changed; and meaningless ConflictErrors on the SessionData object occur, when in fact the state hasn't changed.

Not checking for the equality of states is a reasonable default speed decision for the ZODB.

To fix, we have at least two options.

One is to write an _p_resolveConflict for SessionData that declares the conflict resolved if there is no difference between the two states. This is a bit heavy, but is the more transparent fix.

Another is to change the set access of SessionData._lastAccessTime to be handled with a new method (``setLastAccessTime``), rather than a property. This can be done in such a way that the old property set could still work. This is the more efficient fix. It is still reasonably transparent, given continued support for the old property set.

I intend to fix today using the second approach, releasing as a bugfix in the 3.5 line. 3.6 may want to deprecate the old property set. I will include comments to that effect.

[Gary Poster (gary)]

r87351
released as zope.session 3.5.2