Pre-bound JDBC Connection found

Question

We have an app that is using hibernate, spring, and DB2 in websphere 7. We have audit triggers and we need to set so the triggers can know the logged in user (we use generic logon to the database). We came up with a new scheme for setting this in a new app so that it can automatically join in new transactions. We overrode the transaction manager and did the work in the doBegin.

These scheme worked great in one app, and seemed to work great in a second app, but now, weeks later, and not consistently (behavior is intermittent and does not happen in local development), we are getting this Pre-bound JDBC Connection found error. Looking online most posts say this is when you use two transaction managers against one data source. That is now what we are doing.

I also read one post wondering if it was because he mixed annotation and AOP based transactions. This app does some of that. I don't really buy that theory, but thought I'd mention it.

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()):

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 I never answered this. It turns out that the exception had nothing whatever to do with our Tx manager. It was the fact that this particular EAR has two apps in it, each pointing to the same data source. Evidently this confuses hibernate. We've plans to separate the apps some day, but creating an identical (except in name) data source and pointing the apps at them separately fixes the issue for now.

Answer 2

Instead of modifying the transaction manager it might be easier (better?) to create a wrapper around your datasource (extending DelegatingDataSource from spring) and override the 2 getConnection methods. For the cleanup you could wrap the connection in a proxy and intercept the close method.

That should be a safer (and easier I guess) way then trying to fiddle with the transaction manager and it works for every technology (JDBC, Hibernate, JPA etc.) as long as you use the wrapped datasource. (The registration could be done with a BeanPostProcessor which detects DataSource instances and simply wraps them in the delegate).

If that is to radical (as it means changing your current applications instead of updating a library). It could be a configuration problem, make sure that you are only loading your configuration (and thus DataSource and TransactionManager) only once, duplicating bean instances might lead to a similair behavior.