You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Clement Pang (JIRA)" <ji...@apache.org> on 2011/03/24 04:04:05 UTC

[jira] [Created] (DBCP-355) DataSourceXAConnectionFactory does not store the XAConnection

DataSourceXAConnectionFactory does not store the XAConnection
-------------------------------------------------------------

                 Key: DBCP-355
                 URL: https://issues.apache.org/jira/browse/DBCP-355
             Project: Commons Dbcp
          Issue Type: Bug
    Affects Versions: 1.4, 1.3
         Environment: MysqlXADataSource passed to BasicManagedDataSource
            Reporter: Clement Pang


We have been diagnosing a leak with DBCP and XA mySQL and discovered that the mySQL driver expects close() to be invoked on the XAConnection obtained from xaDataSource.getXAConnection() instead of the java.sql.Connection returned by xaConnection.getConnection();

The following code snippet in DataSourceXAConnectionFactory illustrates how the XAConnection is lost:

    public Connection createConnection() throws SQLException {
        // create a new XAConection
        XAConnection xaConnection;
        if (username == null) {
            xaConnection = xaDataSource.getXAConnection();
        } else {
            xaConnection = xaDataSource.getXAConnection(username, password);
        }

        // get the real connection and XAResource from the connection
        Connection connection = xaConnection.getConnection();
        XAResource xaResource = xaConnection.getXAResource();

        // register the xa resource for the connection
        transactionRegistry.registerConnection(connection, xaResource);

        return connection;
    }

In the code snippet above, the XAConnection is basically discarded after using it to obtain the XAConnection and XAResource. It would be ideal if it actually associates the XAConnection in the transactionRegistry as well so that when PooledManagedConnection handles reallyClose(), it can also invoke close() on the XAConnection by interrogating the TransactionRegistry for the actual XAConnection to close.

This may be something that's mySQL specific.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DBCP-355) DataSourceXAConnectionFactory does not store the XAConnection

Posted by "Clement Pang (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DBCP-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clement Pang updated DBCP-355:
------------------------------

    Description: 
We have been diagnosing a leak with DBCP and XA mySQL and discovered that the mySQL driver expects close() to be invoked on the XAConnection obtained from xaDataSource.getXAConnection() instead of the java.sql.Connection returned by xaConnection.getConnection();

The following code snippet in DataSourceXAConnectionFactory illustrates how the XAConnection is lost:

    public Connection createConnection() throws SQLException {
        // create a new XAConection
        XAConnection xaConnection;
        if (username == null) {
            xaConnection = xaDataSource.getXAConnection();
        } else {
            xaConnection = xaDataSource.getXAConnection(username, password);
        }

        // get the real connection and XAResource from the connection
        Connection connection = xaConnection.getConnection();
        XAResource xaResource = xaConnection.getXAResource();

        // register the xa resource for the connection
        transactionRegistry.registerConnection(connection, xaResource);

        return connection;
    }

In the code snippet above, the XAConnection is basically discarded after using it to obtain the java.sql.Connection and XAResource. It would be ideal if it actually associates the XAConnection in the transactionRegistry as well so that when PooledManagedConnection handles reallyClose(), it can also invoke close() on the XAConnection by interrogating the TransactionRegistry for the actual XAConnection to close.

This may be something that's mySQL specific.

  was:
We have been diagnosing a leak with DBCP and XA mySQL and discovered that the mySQL driver expects close() to be invoked on the XAConnection obtained from xaDataSource.getXAConnection() instead of the java.sql.Connection returned by xaConnection.getConnection();

The following code snippet in DataSourceXAConnectionFactory illustrates how the XAConnection is lost:

    public Connection createConnection() throws SQLException {
        // create a new XAConection
        XAConnection xaConnection;
        if (username == null) {
            xaConnection = xaDataSource.getXAConnection();
        } else {
            xaConnection = xaDataSource.getXAConnection(username, password);
        }

        // get the real connection and XAResource from the connection
        Connection connection = xaConnection.getConnection();
        XAResource xaResource = xaConnection.getXAResource();

        // register the xa resource for the connection
        transactionRegistry.registerConnection(connection, xaResource);

        return connection;
    }

In the code snippet above, the XAConnection is basically discarded after using it to obtain the XAConnection and XAResource. It would be ideal if it actually associates the XAConnection in the transactionRegistry as well so that when PooledManagedConnection handles reallyClose(), it can also invoke close() on the XAConnection by interrogating the TransactionRegistry for the actual XAConnection to close.

This may be something that's mySQL specific.


> DataSourceXAConnectionFactory does not store the XAConnection
> -------------------------------------------------------------
>
>                 Key: DBCP-355
>                 URL: https://issues.apache.org/jira/browse/DBCP-355
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.3, 1.4
>         Environment: MysqlXADataSource passed to BasicManagedDataSource
>            Reporter: Clement Pang
>
> We have been diagnosing a leak with DBCP and XA mySQL and discovered that the mySQL driver expects close() to be invoked on the XAConnection obtained from xaDataSource.getXAConnection() instead of the java.sql.Connection returned by xaConnection.getConnection();
> The following code snippet in DataSourceXAConnectionFactory illustrates how the XAConnection is lost:
>     public Connection createConnection() throws SQLException {
>         // create a new XAConection
>         XAConnection xaConnection;
>         if (username == null) {
>             xaConnection = xaDataSource.getXAConnection();
>         } else {
>             xaConnection = xaDataSource.getXAConnection(username, password);
>         }
>         // get the real connection and XAResource from the connection
>         Connection connection = xaConnection.getConnection();
>         XAResource xaResource = xaConnection.getXAResource();
>         // register the xa resource for the connection
>         transactionRegistry.registerConnection(connection, xaResource);
>         return connection;
>     }
> In the code snippet above, the XAConnection is basically discarded after using it to obtain the java.sql.Connection and XAResource. It would be ideal if it actually associates the XAConnection in the transactionRegistry as well so that when PooledManagedConnection handles reallyClose(), it can also invoke close() on the XAConnection by interrogating the TransactionRegistry for the actual XAConnection to close.
> This may be something that's mySQL specific.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DBCP-355) DataSourceXAConnectionFactory does not store the XAConnection

Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DBCP-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz updated DBCP-355:
-----------------------------

    Fix Version/s: 1.4.1
                   1.3.1

> DataSourceXAConnectionFactory does not store the XAConnection
> -------------------------------------------------------------
>
>                 Key: DBCP-355
>                 URL: https://issues.apache.org/jira/browse/DBCP-355
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.3, 1.4
>         Environment: MysqlXADataSource passed to BasicManagedDataSource
>            Reporter: Clement Pang
>             Fix For: 1.3.1, 1.4.1
>
>
> We have been diagnosing a leak with DBCP and XA mySQL and discovered that the mySQL driver expects close() to be invoked on the XAConnection obtained from xaDataSource.getXAConnection() instead of the java.sql.Connection returned by xaConnection.getConnection();
> The following code snippet in DataSourceXAConnectionFactory illustrates how the XAConnection is lost:
>     public Connection createConnection() throws SQLException {
>         // create a new XAConection
>         XAConnection xaConnection;
>         if (username == null) {
>             xaConnection = xaDataSource.getXAConnection();
>         } else {
>             xaConnection = xaDataSource.getXAConnection(username, password);
>         }
>         // get the real connection and XAResource from the connection
>         Connection connection = xaConnection.getConnection();
>         XAResource xaResource = xaConnection.getXAResource();
>         // register the xa resource for the connection
>         transactionRegistry.registerConnection(connection, xaResource);
>         return connection;
>     }
> In the code snippet above, the XAConnection is basically discarded after using it to obtain the java.sql.Connection and XAResource. It would be ideal if it actually associates the XAConnection in the transactionRegistry as well so that when PooledManagedConnection handles reallyClose(), it can also invoke close() on the XAConnection by interrogating the TransactionRegistry for the actual XAConnection to close.
> This may be something that's mySQL specific.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira