Prelinked JDBC Connection Found

Question

We have an application that uses hibernate, spring and DB2 in websphere 7. We have audit triggers, and we need to set it so that the triggers can know the logged-in user (we use the shared database login). We came up with a new scheme for installing this in a new application so that it can automatically join new transactions. We redefined the transaction manager and did the work in doBegin.

This circuit worked fine in one application and seemed to work fine in the second application, but now, after several weeks and not sequentially (the behavior is intermittent and does not occur in local development), we get this preliminary binding JDBC connection error. Looking on the Internet, most posts talk about this when you use two transaction managers against a single data source. This is what we do.

I also read one post, wondering if this was because it was mixing annotations and transactions based on AOP. This app does some of them. I really don't buy this theory, but thought I mentioned it.

An exception:

Caused by: org.springframework.transaction.IllegalTransactionStateException: Pre-bound JDBC Connection found! HibernateTransactionManager does not support running within DataSourceTransactionManager if told to manage the DataSource itself. It is recommended to use a single HibernateTransactionManager for all transactions on a single DataSource, no matter whether Hibernate or JDBC access. at java.lang.Throwable.<init>(Throwable.java:67) at org.springframework.core.NestedRuntimeException.<init>(NestedRuntimeException.java:54) at org.springframework.transaction.TransactionException.<init>(TransactionException.java:34) at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:475) at gov.usdoj.afms.umc.utils.hibernate.AfmsHibernateTransactionManager.doBegin(AfmsHibernateTransactionManager.java:28) 

Code (note that the exception comes from the super.doBegin () file):

 protected void doBegin(Object arg0, TransactionDefinition arg1) { super.doBegin(arg0, arg1); if (!Db2ClientInfo.exists()) { clearDBProperty(); } else { setDBProperty(Db2ClientInfo.getClientUserId(), Db2ClientInfo.getClientApplicationId()); } } private void setDBProperty(String uId, String appName) { Session session = getSessionFactory().getCurrentSession(); Properties props = new Properties(); props.setProperty(WSConnection.CLIENT_ID, uId); props.setProperty(WSConnection.CLIENT_APPLICATION_NAME, appName); try { Connection nativeConn = new SimpleNativeJdbcExtractor().getNativeConnection(session.connection()); if (nativeConn instanceof WSConnection) { WSConnection wconn = (WSConnection) nativeConn; wconn.setClientInformation(props); } else { logger.error("Connection was NOT an instance of WSConnection so client ID and app could not be set"); } } catch (Exception e) { throw new RuntimeException("Cannot set DB parameters!", e); } } 

Answer 1

I just realized that I never answered that. It turns out that the exception had nothing to do with our Tx manager. It was the fact that this particular EAR has two applications in it, each of which points to the same data source. Obviously, this is confusing sleep mode. We plan to separate applications once, but creating an identical (except for the name) data source and pointing applications to them separately fixes the problem at the moment.

Answer 2

Instead of changing the transaction manager, it might be easier (better?) To create a wrapper around your data source (extension DelegatingDataSource from spring) and override the two getConnection methods. For cleaning, you can bind the connection in the proxy and intercept the close method.

This should be a safer (and easier than I guess) way, and then try to mess with the transaction manager, and it works for every technology (JDBC, Hibernate, JPA, etc.) if you use a wrapped data source. (Registration can be done using BeanPostProcessor , which detects DataSource instances and simply transfers them to the delegate).

If it is radical (as it means changing your current applications instead of updating the library). This may be a configuration problem, make sure that you only load your configuration (and therefore DataSource and TransactionManager) only once, duplicating bean instances can lead to a similar situation.

Answer 3

For posterity, I just got this problem and the answers here were not very helpful. We solved the problem by removing the double import of the main XML file in which the AOP transaction manager definition was defined:

 <tx:annotation-driven transaction-manager="..." proxy-target-class="true" /> 

I think this leads to the fact that 2 transaction managers overlap the same namespace. To fix this, we moved the imports so that they run once.

Hope this helps someone else.