[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.

[Rafael Chaves (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_28363 ] 

Rafael Chaves commented on HHH-2627:
------------------------------------

I am seeing this same issue. But shouldn't the connection#close be enough to release any database resources? 

I tried working around this problem by providing Hibernate with a proxied connection that remembers all statements created (using weak references) and closes then when the connection is closed, but that does not seem to fix the problem.

Does anyone have a workaround to suggest? Thanks.

> Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
> ----------------------------------------------------------------------------
>
>                 Key: HHH-2627
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627
>             Project: Hibernate3
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.2.3, 3.2.4, 3.2.4.sp1
>         Environment: Hibernate 3.2.2-4sp1, Oracle 10g (Oracle9Dialect)
>            Reporter: Michael Werle
>            Assignee: Gail Badner
>         Attachments: generated-lazy-statement-leak.patch, HHH-2627-AbstractBatcher_prepareSelectStatement.patch, HHH-2627-SharedPKOneToOne.patch, HHH-2627-testcase.patch
>
>
> The fix for HHH-2393, in combination with a change to AbstractBatcher 11333 to the Hibernate 3.2 branch (comment is "sybase testsuite"), created a PreparedStatement leak for generated properties.
> The reason is that, in revision 11333, org.hibernate.jdbc.AbstractBatcher#closeQueryStatement() was changed to check for the existence of the prepared statement in the statementsToClose collection instead of closing it unconditionally.  The fix for HHH-2393 (revision 11117 in the Hibernate 3.2 branch) modified org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties() to make it use org.hibernate.jdbc.AbstractBatcher#closeQueryStatement() instead of org.hibernate.jdbc.AbstractBatcher#closeStatement(), which closes the statement without checking the statementsToClose collection.  This is a problem because the statement in AbstractEntityPersister#processGeneratedProperties() is created with AbstractBatcher#prepareSelectStatement(), which does not add the statement to the statementsToClose collection.
> The attached patch to org.hibernate.persister.entity.AbstractEntityPersister changes processGeneratedProperties() back to using AbstractBatcher#closeStatement() and obtains the result set through ResultSet#executeQuery() instead of using the batcher.  This fixes the prepared statement leak and matches other usages of AbstractBatcher#prepareSelectStatement(), which also avoid using the batcher for their result sets.  It also makes the same change in AbstractEntityPersister#initializeLazyPropertiesFromDatastore() becuase it has exactly the same problem.
> No existing test cases are broken by the attached patch.  I investigated ways to write a test case to explicitly verify that the result sets and statements were all being closed.  However, because the counts in AbstractBatcher are private, and I do not know of a generic way to obtain counts through the JDBC API, I could not figure out a good way to do so without using reflection to access the private fields, which none of the existing test cases seem to do.
> The bug was discovered when running my web app against Oracle, which runs out of cursors when connections are leaked -- not exactly a practical way to write a test case, but sufficient to prove that the bug exists and is fixed by the patch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira