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

[Willem Voogd (JIRA)]

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

Willem Voogd commented on HHH-2627:
-----------------------------------

okay, so it's kind of confusing this way, when you use prepareSelectStatement you *cannot* let the Batcher close your statement, and when you use prepareQueryStatement you *have to* let the Batcher close your statement. That cannot be right, either you leave everything to the Batcher, or you do it all yourself, IMHO. 
Also, i don't see the point in having the Batcher keeping track of Statements when it only does it in some cases. So i guess the proper fix would be to let all cases where the Batcher hands out a Statement having it keeping track of it and alle cases where the Batcher is asked for it, let the Batcher also clean it up. For now i'll just scratch my own itch by the imperfect patch then ;)

> 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
>         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