[Zope3-dev] a ConflictError grabbag: problems and solutions in zope.app.keyreference and zope.app.session

[Dieter Maurer]

Gary Poster wrote at 2007-6-13 17:12 -0400:
> ...
>2) The second problem is less serious, but still evidenced in our  
>production apps, and representative of a class of problems I've  
>wanted to address for awhile.  zope.app.session writes to a session  
>if it is accessed  
>zope.app.session.session.PersistentSessionDataContainer.resolution  
>seconds after a session data was last updated, to indicate that the  
>session is still active.  It scribbles time.time().  The default  
>resolution is 50 minutes.
>
>Given a page that makes several requests, it is very easy (speaking  
>as an observer of server logs) to generate conflict errors in a  
>modern browser that parallelizes requests for resources on a page,  
>once the time comes to update.
>
>I'd like to make a module that contains two very simple classes,  
>similar to BTrees.Length, that are persistent objects that hold a  
>single value, and have simple resolution policies.  One would always  
>prefer the greater or equal value of the two new values, and the  
>other would prefer the lesser or equal value of the two new options.   
>The session code, as well as other similar expiration-based use  
>cases, could use these classes to store the time.time() float--the  
>session code would use the max variant.

I doubt that this will help you much (we use such an implementation
for many years and still see quite often session related conflicts).
The reason:

  Sessions are often in a temporary storage and this has a very
  restricted history.

  For conflict resolution, a sufficiently large history is
  necessary (long enough to load the old state again).

  Very often, the available history is not long enough to
  resolve a conflict.



-- 
Dieter