See http://forum.springsource.org/showthread.php?t=95980 for a description of the problem.
Here's the description that I copy/pasted from the Spring forums: In Websphere I was able to wire an interceptor around all of my controllers and set thread-bound DB credentials based on the path of the current request. In my tcServer Developer edition (2.3.3 M1) this no longer works. My datasource is wired as a org.springframework.jdbc.datasource.UserCredential sDataSourceAdapter I've verified that I'm calling the getConnection(String username, String password) method with the correct credentials. However, the connection that is returned is of type ProxyConnection[PooledConnection[oracle.jdbc.driver.T4CConnection@6ab4a7]] with the same default credentials as those defined in server.xml. Is there another way to set the database credentials at runtime?
Do you have a code example to show how you receive this error? Or perhaps even a JUnit test?
(In reply to comment #2) > Do you have a code example to show how you receive this error? Or perhaps even > a JUnit test? Take a look at the source code for getConnection. It was included in a reply to my original post in the forums (reproduced below). --- This is an issue with the new jdbc-pool implementation, it internally always uses the default configured username/password. I suggest raising a bug on the tomcat(jdbc-pool) issue tracker. The actual code. Code: public class DataSourceProxy implements PoolConfiguration { ... /** * {@link javax.sql.DataSource#getConnection()} */ public Connection getConnection(String username, String password) throws SQLException { return getConnection(); } .... }
hi Tim, this isn't really a bug, but how the pool operates. This is a pool, meaning it caches connections with a predefined set of credentials as defined in the configuration. If we allowed the username/password to be passed, the cache would have to be way more sophisticated, since it could mean that we would have to close a connection, and open a new one with the provided credentials. So in the worst case scenario, you'd really not have a pool. I started working on a simple patch, that would simply reuse the existing cache, and see if the connection had the requested credentials already. This way, the speed is not compromised on the cache, but could lead to unnecessary disconnect/reconnects. I can show you the patch, attached. (just needs some additional calls to complete it) But my gut feel, is that this isn't really a bug. If implemented as a feature, it would need some serious though to not compromise the performance of the existing implementation.
Created attachment 26363 [details] Beginning of a patch to handle DataSource.getConnection(username,password) for a pool
Created attachment 26455 [details] Patch to allow the call DataSource.getConnection(username,password) Here is the patch for allowing DataSource.getConnection(username, password) to be used. In the case of a connection that is connected, is used with a different username, password it is reconnected. I'm hesitant to apply this patch at this time as it does slow down the pool doing the passwords checks every time a connection is requested. I will experiment with a flag to enable/disable the check
Fixed in version 1.0.9.1 http://people.apache.org/~fhanik/jdbc-pool/