You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org> on 2008/04/04 16:31:24 UTC

[jira] Commented: (DERBY-3596) Creation of logical connections from a pooled connection causes resource leak on the server

    [ https://issues.apache.org/jira/browse/DERBY-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585549#action_12585549 ] 

Dyre Tjeldvoll commented on DERBY-3596:
---------------------------------------

My understanding is that the statement cache is only available when using ClientConnectionPoolDataSource. Perhaps we should include a reference to this issue in the description of the statement cache feature in the release notes? Seems like anyone wanting to try out the statement cache will likely experience this problem.

> Creation of logical connections from a pooled connection causes resource leak on the server
> -------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3596
>                 URL: https://issues.apache.org/jira/browse/DERBY-3596
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client, Network Server, Performance
>    Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.0, 10.5.0.0
>            Reporter: Kristian Waagan
>         Attachments: ConnectionPoolingBug.java
>
>
> When using ClientConnectionPoolDataSource and connection pooling, a new connection / transaction is created for every new logical connection, and the resources are not freed / cleaned up in the server. They are not even cleaned up when the physical connection (ClientPooledConnection) is closed.
> A logical connection is obtained by invoking ClientPooledConnection.getConnection().
> I have observed that if you run the repro enough times against the same server, the number of transaction in the transaction table will be reduced now and then. I believe this is garbage collection, but I have not investigated the problem enough to tell for sure what's going on.
> I have also seen some locks not being freed, causing timeouts in some applications. I don't have a repro for the lock problem at this time, but it is very likely related to this issue.
> Note that XA connections are handled differently on the server, and do probably not have this problem.

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