[Zope] HappySession

[Pavlos Christoforou]

On Fri, 1 Sep 2000, Dieter Maurer wrote:

> I can tell you, that FSSession has the same problem, at least
> the version before the current one (announced some days ago).

FSSession has no longer such problem. However you might still loose data
if you access the same SessionUID from many frames. I don't thing there is
a general solution to the problem without involving read locks which will
slow down the whole Zope site. Or raising ConflictErrors which for frame
usage like the case you mention will occur very often. The same problem
will occur whether you store the Session info in an RDBMs or not. For
instance:

Thread A reads Session1
Thread B reads Session1
Thread A modifies Session1 and commits
Thread B modifies Session1 and commits.

This creates a conflict and the solution I have chosen is to keep the last
to commit. In general we can achieve very high write rates because there
is a natural isolation among requests, one thread per SessionUID. Problems
will occur if multiple concurrent requests try to access the same
SessionUID. This could occur in situations that employ frames but (at
least in our case) most of the time the Session info is required only in
one frame. In any case I have tested the latest version of FSSession
against multiple frames accessing the same SessionUID and I do not get
TransactionErrors.

Actually there is a slightly better way but it will involve a lot of
complicated programming so I won't even mention it ... :-)

Pavlos