[
https://issues.apache.org/jira/browse/OPENJPA-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573589#comment-13573589
]
Kathey Marsden commented on OPENJPA-2329:
-----------------------------------------
Again appologies for my lack of OpenJPA knowledge. I am a Derby engineer, not
really in a position to look at the OpenJPA code. I observed the possible
issue with a Derby tool. I had asked the user to run:
java org.apache.derby.drda.NetworkServerControl runtimeinfo which yielded many
calls to SYSIBM.SQLCOLUMNS e.g.
Prepared Statement Information:
Stmt ID SQLText
------------- -----------
SYSLH00034 CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)
SYSLH00013 CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)
SYSLH00012 CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)
SYSLH00015 CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)
SYSLH00014 CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)
Which would correspond to DatabaseMetaData.getColumns()
Also there were many
CALL SYSIBM.SQLFOREIGNKEYS(?,?,?,?,?,?,?)
CALL SYSIBM.SQLFOREIGNKEYS(?,?,?,?,?,?,?)
Which would correspond to getImportedKeys()
Perhaps looking for calls to these methods and DatabaseMetaData in the OpenJPA
code would show the result sets whose statements are not closed. It is not
intuitive to close them as you never create the statement explicitly but can
get at it with ResultSet.getStatement() call.
I am not sure if there are other DatabaseMetaData calls that might be in
OpenJPA that are not closed, but these are the ones that showed up in Derby
runtimeinfo.
It would have been better for the OpenJPA user to file this but he just said
he didn't have time, so I thought I would file something vague here, even
though I have limited visibility from where Derby is in the picture.
> OpenJPA should close JDBC metadata (and all) statements
> --------------------------------------------------------
>
> Key: OPENJPA-2329
> URL: https://issues.apache.org/jira/browse/OPENJPA-2329
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: SuSE linux vm loaded to the point that garbage
> collection not likely to kick in
> Reporter: Kathey Marsden
>
> Please close all JDBC Metadata statements after execution in OpenJPA to
> avoid a potential interaction issue with Derby Network Client. See details
> at: https://issues.apache.org/jira/browse/DERBY-6055.
> The statement can be obtained with ResultSet.getStatement() e.g.
> for (int i = 0; i < 50000; i++) {
> ResultSet rs = conn.getMetaData().getSchemas();
> while (rs.next()) {
> //System.out.println("SCHEM NAME = " + rs.getString(1));
> }
> rs.getStatement().close(); <====
> }
> In debugging a recent DERBY client/OpenJPA interaction issue, I saw in that
> there were a fair number of JDBC metadata Result Sets that did not get
> cleaned up until garbage collection kicked in.
> There is a program in-lined in the description of DERBY-6055 that shows how
> metadata statements can build up and could potentially exceed the maximum
> number of sections if garbage collection did not kick in on time on a loaded
> system.
> Sorry for the lack of OpenJPA version detail and repro as I don't have any
> personal experience with OpenJPA and was not able to get information on
> OpenJPA version from the user. The user's primary statement issue was a
> different so they did not have time to follow up on this potential one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
