openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee (JIRA)" <>
Subject [jira] Commented: (OPENJPA-415) Garbage collection of AbstractResultList instance closes active connection
Date Wed, 24 Oct 2007 18:24:51 GMT


Albert Lee commented on OPENJPA-415:

Another finding is: the AbstractResultList.finalize() also causing some thread safety issues
for some connection manager that does not support mutli-threaded access. I was told that in
general JDBC driver, connection manager etc do not require to support multi-thread. This means
closing connection from gc's finalize method, which is executed in a different thread, may
cause problems. This is the original observed problem that I was trying to resolve.

By not doing explicit gc in AbstractResultList, both of the described problems were resolved.
I have also looked at the heap dump snapshots taken during a 20 hours application run, I did
not see any abnormal openjpa object (memory) leakage other than the normal heap growth by
other application components.

Are there any reasons the AbstractResultList.finalize() can NOT be removed?

Albert Lee.

> Garbage collection of AbstractResultList instance closes active connection
> --------------------------------------------------------------------------
>                 Key: OPENJPA-415
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.0.1, 1.1.0
>            Reporter: Albert Lee
> While investigation a problem, I noticed that garbage collection kicks in on the AbstractResultList's
finalize() method.
>         ........
>         at org.apache.openjpa.lib.jdbc.DelegatingConnection.close(
>         at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection.close(
>         at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$
>         at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$RefCountConnection.close(
>         at org.apache.openjpa.jdbc.sql.ResultSetResult.close(
>         at org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.close(
>         at
>         at org.apache.openjpa.lib.rop.WindowResultList.close(
>         at org.apache.openjpa.lib.rop.AbstractResultList.finalize(
>         at java.lang.J9VMInternals.runFinalize(
> When traversing the call stack to the ResultSetResult.close() method, it is trying to
close the result set unconditionally, and then close the associated statement and connection
if they exists:
>     public void close() {
>         super.close();
>         try {
>             _rs.close();
>         } catch (SQLException se) {
>         }
>         if (_stmnt != null)
>             try {
>                 _stmnt.close();
>             } catch (SQLException se) {
>             }
>         if (_closeConn)
>             try {
>                 _conn.close();
>             } catch (SQLException se) {
>             }
>     }
> Would this be a undesired side-effect and a problem in the following scenario:
> 1)  appl / openjpa obtains a connection
> 2)  create a prepare statement 
> 3)  get a result set from the statement
> 4)  using the same statement and get another result set. The first result set is not
being referenced by any code and ready for gc.
> 5)  the connection and statement is active for a long time and gc kicks in to gc the
first result set instance
> 6)  eventually the ResultSetResult.close() gets call.
> 7)  The statement and connection gets closed while it is still being used by appl / openjpa.
> Is this a possible scenario? 
> According to the JCA architecture, connection that is scoped to a transaction will be
closed by the connection manager and all associated statements and result set managed by the
connection will be automatically closed. So is the AbstractResultList.finalize() ever be needed
at all? 
> Albert Lee.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message