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
