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 _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
