[
https://issues.apache.org/jira/browse/CASSANDRA-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117529#comment-13117529
]
Rick Shaw commented on CASSANDRA-3244:
--------------------------------------
I think this driver assumes its connection is not reusable by a pool. It
maintains state and JDBC currently has no interface methods to manage the
notion of clearing and cleaning up its state separate from closing the physical
connection, just {{close()}}. It needs to be done by cooperating {{protected}}
methods. This will be fine if we implement our own {{PooledConnection}} classes
but is not really practical for frameworks that want to wrap our {{Connection}}
implementation. The drastic solution is to give up maintaining state and
therefor (at least in my opinion) breaking the best effort contract to adhere
to the spec where we can to make an external cooperating framework function.
Note that there is really no problem with not closing the connection if the
{{Statement}} is closed. It will just leave an empty list of statements. The
patch forces the {{Statement}} to clean up the list when it closes. But of
course the _potential_ problem remains. This is all done because the spec says
the statements should be closed on premature close of the connection. There is
a whole section in the spec on how pools should be handled.
The only approach I can think of is to split {{CassanadraConnection}} in two
and wrap the physical connection and keep state in the wrapper. That (I think)
is the approach of {{PooledConnection}} anyway.
Do you think this is urgent? Can it wait toll we implement our own JDBC
compliant pooling classes?
> JDBC CassandraConnection may lead to memory leak when used in a pool
> --------------------------------------------------------------------
>
> Key: CASSANDRA-3244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3244
> Project: Cassandra
> Issue Type: Improvement
> Components: Drivers
> Affects Versions: 1.0.0
> Reporter: Patricio Echague
> Assignee: Rick Shaw
> Priority: Minor
> Labels: JDBC
> Fix For: 0.8.7
>
> Attachments: 3244-v1.txt
>
>
> I may be wrong here but I noticed that the implementations of
> CassandraConnection#createStatement() and
> CassandraConnection#prepareStatement() keep(cache) the created
> Statement/PrepareStatement internally in a List.
> They list is freed up only during CassandraConnection.close() which makes me
> think that, if the connection object is used in a pool implementation, it
> will lead to a memory leak as it will hold every single statement that is
> used to interact with the DB until the connection gets closed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
