tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Suggestion for new Session Manager
Date Fri, 07 Apr 2006 21:33:49 GMT
take a look at the PersistentManager

Marc Riehm wrote:
> I would like to make a suggestion for a new Tomcat Session Manager.
> I've been using Tomcat heavily for 5 years now at my work:<>.
We have multiple Tomcat instances, but sessions are bound to individual instances. I've toyed
with the idea of clustering, but I've shied away from it because I have concerns about race
conditions in a frameset. Our tomcat apps make very heavy use of nested frames, and I'm concerned
that in that environment, two requests may hit the server "simultaneously", and they may both
modify the session. The result would be (I believe) a race condition, leaving the state of
the session indeterminate after the two requests finish.
> It might be nice to have a Session Manager with the following characteristics:
> 1) Centralized session storage;
> 2) Session locking for the duration of a request (thus avoiding the race condition described
> 3) Persistence.
> One good way to implement such a Manager would be using an RDBMS. During the processing
of a request, if the servlet accessed the Session (request.getSession()), the Manager would
retrieve it from the RDBMS, using a write lock (e.g. "SELECT .... FOR UPDATE" in MySQL). Upon
completion of the request, the Manager would write the Session back to the database and COMMIT.
This would be done in a transactional manner, so that a lock would be held on the record for
the duration of the request.
> Session timeout would have to be handled via periodic checks to the database, querying
for sessions that had not been accessed in a while.
> This would be a very clean, safe way to deal with the race condition scenario. Plus of
course persistence comes for free.
> The implementation would have to be done carefully, using JDBC connection pooling. The
implementation described above implies that a JDBC connection would have to be held open for
the duration of the request processing. This would have to be done very carefully. A try/finally
block should be used, where the resources (JDBC connection + transaction + lock) would be
released in the finally block.
> The disadvantage here is performance. In my scenario above the two requests would be
serialized (the second would block until the first was complete). But I do not think that
that would be a big hit for many apps. Some extra latency loading the session would be incurred,
but again for many apps I don't think that would be substantial. Also, one JDBC connection
would have to be held for the duration of each session-sensitive request, so this might not
be appropriate for applications with very large numbers of users.
> I looked through the 5.5.16 code a bit. One issue that I see is that the Manager interface
would not easily support a try/finally construct like that described above. The implementation
would have to guarantee that the transaction was terminated and the JDBC connection freed
up at the end of each request, and I'm not sure how to achieve that in Catalina 5.5.
> Does anyone have any comments? If there was support for this idea, and if one of the
tomcat developers was willing to point me in the right direction, I would certainly consider
contributing the implementation.
> Thanks, --Marc Riehm

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message