[
https://issues.apache.org/jira/browse/DERBY-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3596:
-----------------------------------
Derby Info: (was: [Patch Available])
Fix Version/s: 10.5.0.0
Thank you for looking at the new patches Knut Anders.
Committed 'derby-3596-5a-complex_skip_creds.diff' to trunk with revision 666088.
This must be backported to 10.4, but I want to wait for a while to see if any
issues are detected.
I think this patch concludes the work on the issue unless new problems surface.
Note that I discovered a performance issue that I will handle under DERBY-3441.
The client driver reset procedure causes the query "VALUES CURRENT SCHEMA" to
be executed on every connection reset. I will post more details under the
mentioned Jira issue.
> 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.3, 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.5.0.0
>
> Attachments: complex-fix-heap.png, ConnectionPoolingBug.java,
> derby-3596-1a-complex_approach.diff, derby-3596-1b-complex_approach.diff,
> derby-3596-2a-simple_approach.diff, derby-3596-3a-test_cleanup.diff,
> derby-3596-4a-complex_check_creds.diff,
> derby-3596-5a-complex_skip_creds.diff, nofix-heap.png, simple-fix-heap.png
>
>
> 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.
