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 "Kristian Waagan (JIRA)" <ji...@apache.org> on 2008/05/21 16:39:55 UTC
[jira] Updated: (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:all-tabpanel ]
Kristian Waagan updated DERBY-3596:
-----------------------------------
Attachment: derby-3596-1a-complex_approach.diff
derby-3596-2a-simple_approach.diff
I have uploaded two fixes that solve the problem.
None of them are ready for commit, but I'd like to get some comments
on which approach to go for.
* 'derby-3596-1a-complex_approach.diff'
Solves the problem by maintaining only one physical connection on the
server side. This connection has to be reset, which includes setting
the isolation level, resetting IDENTITY_VAL_LOCAL and cleaning out
temporary tables.
The patch basically contains two parts: Detecting and handling a
deferred reset in DRDAConnThread and exposing / extending reset
functionality (the connection classes).
A drawback of this approach is that care must be taken to get the
reset logic correct.
* 'derby-3596-2a-simple_approach.diff'
Solves the problem by simply closing the existing connection on the
server side before creating a new, if there is one.
Only a few lines of code.
This solution is far from optimal, since a physical connection is both
closed and created on the server for each logical connection on the
client side.
* Optimal approach
This would probably be to rewrite the whole logic, both on the client
and the server side. It seems to me there is half-baked support for a
lot more advanced functionality than what we are using. I see what we
have / had as a first step towards supporting enterprise multi-tiered
connection pooling ala what DB2 has. There is support for this in
DRDA, where for instance a pooling agent can use a single connection
to do work for multiple clients/drivers (one must switch database and
user "on the fly").
I'll attach a few graphs showing the heap usage of the various
approaches, and also provide a few numbers regarding performance.
I'm asking for comments on this 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
> Attachments: ConnectionPoolingBug.java, derby-3596-1a-complex_approach.diff, derby-3596-2a-simple_approach.diff
>
>
> 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.