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:
http://www.maptuit.com<http://www.maptuit.com/>. 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 above);
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
