Created attachment 23518 [details] Patch JDBCStore to use datasource. We are using the JDBCStore to store sessions. The current implementation can only be configured with database connection parameters. Each web application will create and hold on to its own connection to the session store. Our tomcats contain a large number of webapps, and this causes and unduly large number of connections to be made to the database. In addition, all our other database connections are configured using datasources, and so for consistency we would much prefer to use a datasource. I have patched JDBCStore to allow the use of datasource to obtain the connection. I have added a parameter called "datasourceName". If this is defined it will use this to lookup the datasource in JNDI. If it is not configured, it will fall back to using direct connection. Patch is attached.
Created attachment 23521 [details] Patch JDBCStore to use datasource v2. Supplied updated version of patch
A couple of comments on your patch: - It appears to more than advertised - eg moving the call to remove(). Should this be a separate issue? - The documentation is not updated. - Think about the visibility of the new attributes and methods you are adding. I'd probably start them off as private and increase visibility of required.
Created attachment 23639 [details] JDBCStore.java patch 1
Created attachment 23640 [details] JDBCStore.java patch 2
The patch does indeed move the remove() method. This is because in the original code, the call to remove() is inside the block of code in save(), which gets the connection. But the remove() method then gets the connection again! This isn't such a problem for the "direct connection" method as the connection is left open after remove() has finished with it. But in the case where the datasource is being used, the remove() method returns the connection, and then the connection is then not available to the rest of the save() method. As you mentioned, maybe this is a separate issue, so I have posted this a separate patch (patch 1), so that if you decide to treat it separately it will be easier to do so. The other patch (patch 2) adds in the code required for datasource support using JNDI lookup as before. I have also made the new member variables private as suggested. This patch needs to be applied after patch 1.
Created attachment 23778 [details] New version of JDBCStore supporting datasource only I have also come up with an alternative for the JDBC session store. Attached JDBCStoreDS.java is a new file which ONLY supports the datasource method of getting the connection. Therefore this doesn't require any changes to the existing "direct connection" version of the code. The code can be used by adding the following into context.xml <Manager className="org.apache.catalina.session.PersistentManager" maxIdleBackup="0"> <Store className="org.apache.catalina.session.JDBCStoreDS" datasourceName="java:/comp/env/jdbc/DB-TOMCAT" sessionDataCol="session_data" sessionIdCol="session_id" sessionLastAccessedCol="last_access" sessionMaxInactiveCol="max_inactive" sessionTable="tomcat_sessions" sessionValidCol="valid_session"> </Store> </Manager> where DB-TOMCAT is a datasource defined elsewhere. There is also an optional parameter "requireDistributable". Setting this to true will mean sessions will only be persisted to the database if the webapp is marked as "distributable" in the web.xml. The default is false which means the the sessions will be persisted anyway.
This was implemented (slightly differently for Tomcat 7). I don't see this feature being back-ported to Tomcat 6. *** This bug has been marked as a duplicate of bug 51264 ***