Resolution: Won't Fix
Affects Version/s: 2.1.0, 2.1.1, 2.1.2, 2.2.0, 2.2.1, 2.2.2, 2.2.3
Fix Version/s: None
CLE Team Issue:Yes
To support cross-tool web sessions in a clustered environment, Sakai currently forces each user session to stay on a single server. Unfortunately, it stores the association of user-server and session in the enterprise database. Also, despite the volatile and transient nature of the information, Sakai does not delete the session record. Instead, when a session ends, the existing session record is updated with a SESSION_END time.
As a result, this table grows very large, is filled overwhelmingly with obsolete data, and is very frequently queried. In the current UC Berkeley pilot installation, the single most frequent SAKAI_SESSION query consumes 0.5 days of CPU time every day.
A lighter-weight alternative design should be investigated. The server ID could be maintained client-side, for example. (This might also avoid a frequent problem we've encountered in which a user is unable to log back onto Sakai after failure of the server they were on.)
Or the entire issue of sessions on a cluster might be eliminated. In Tomcat 5.5, support for cross-context session replication has been added. This possibly enables radical simplification of Sakai's inter-component code:
At the very least, while the current design remains in place, automatic SAKAI_SESSION clean-up should be configurable.