[
https://issues.apache.org/jira/browse/DERBY-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3596:
-----------------------------------
Attachment: derby-3596-1b-complex_approach.diff
'derby-3596-1b-complex_approach.diff' removes (now) redundant code (added under
DERBY-3690) and cleans up the patch a little bit. It is actually pretty simple,
and I'm leaning towards implementing this approach instead of the one I have
called simple.
The simple one causes some test errors, because of some internal state on the
server gets inconsistent.
Since the complex one is not that complex and gives better performance, I'm
strongly considering choosing it over the other solution.
I would be grateful if someone could have a look at the patch and comment on it
(again) or ask questions.
FYI, the client sends a "reconnect sequence" every time a logical connection is
created on the client; EXCSAT, ACCSEC, SECCHK and ACCRDB.
This is probably not the last spin, I have to check if there are other
connection properties that have to be reset for logical connection.
> 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
> 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,
> 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.
