[jira] Created: (DBCP-327) XAConnection is not closed

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (DBCP-327) XAConnection is not closed

Richard (Jira)
XAConnection is not closed
--------------------------

                 Key: DBCP-327
                 URL: https://issues.apache.org/jira/browse/DBCP-327
             Project: Commons Dbcp
          Issue Type: Bug
    Affects Versions: 1.4
         Environment: MySQL Connector/J 5.1.12; JOTM 2.1.9; propesed solution is tested with Derby 10.5.3.0_1 as well
            Reporter: Sergey Vladimirov
            Priority: Minor
             Fix For: 1.3.1


After creation of connection in DataSourceXAConnectionFactory::createConnection() the instance of XAConnection is ready to be garbage collected. But in MySQL Connector/J this instance holds the real physiscal connection to MySQL server. Thus, simple test case (in attach) opens 2 connections to server and the first one can be considered as "leak".

The possible solution is to close "parent" XA connection as soon as "child" Connection is closed as well. Due to compatibility issues it may be an option for BasicManagerDataSource. However, Derby seems okay with both variants (according to my test cases with JOTM/Hibernate/Derby/DBCP(+-patch))

In the attachment - "manual" test case, since i don't know how to count real MySQL connection number in runtime. When BasicManagedDataSource is used (change it at ~43) we can create breakpoint at line "connection.close();" (~115). According to MySQL Administrator there are 2 connections, but according to pool - only one. If BasicManagedDataSourceXAClose is used - first connection correclty closed.

This issue created serious problems in out production system, but, due to existing workaround (replace BasicManagedDataSource and DataSourceXAConnectionFactory) priority is minor.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (DBCP-327) XAConnection is not closed

Richard (Jira)

     [ https://issues.apache.org/jira/browse/DBCP-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Vladimirov updated DBCP-327:
-----------------------------------

    Attachment: MySQL and DBCP.zip

> XAConnection is not closed
> --------------------------
>
>                 Key: DBCP-327
>                 URL: https://issues.apache.org/jira/browse/DBCP-327
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: MySQL Connector/J 5.1.12; JOTM 2.1.9; propesed solution is tested with Derby 10.5.3.0_1 as well
>            Reporter: Sergey Vladimirov
>            Priority: Minor
>             Fix For: 1.3.1
>
>         Attachments: MySQL and DBCP.zip
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> After creation of connection in DataSourceXAConnectionFactory::createConnection() the instance of XAConnection is ready to be garbage collected. But in MySQL Connector/J this instance holds the real physiscal connection to MySQL server. Thus, simple test case (in attach) opens 2 connections to server and the first one can be considered as "leak".
> The possible solution is to close "parent" XA connection as soon as "child" Connection is closed as well. Due to compatibility issues it may be an option for BasicManagerDataSource. However, Derby seems okay with both variants (according to my test cases with JOTM/Hibernate/Derby/DBCP(+-patch))
> In the attachment - "manual" test case, since i don't know how to count real MySQL connection number in runtime. When BasicManagedDataSource is used (change it at ~43) we can create breakpoint at line "connection.close();" (~115). According to MySQL Administrator there are 2 connections, but according to pool - only one. If BasicManagedDataSourceXAClose is used - first connection correclty closed.
> This issue created serious problems in out production system, but, due to existing workaround (replace BasicManagedDataSource and DataSourceXAConnectionFactory) priority is minor.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.