db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3596) Creation of logical connections from a pooled connection causes resource leak on the server
Date Wed, 21 May 2008 14:39:55 GMT

     [ 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

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
> -------------------------------------------------------------------------------------------
>                 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:,,,,
>            Reporter: Kristian Waagan
>         Attachments: ConnectionPoolingBug.java, derby-3596-1a-complex_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
> 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.

View raw message