]
Gail Badner commented on HHH-2627:
----------------------------------
After reviewing around 15 usages, it looks like both conventions are in place. I agree
that only one convention should be used, but I'm not sure which one is preferred.
The only way to adhere to either of these is to copy-and-paste and tweak an existing
usage, which is very error-prone and difficult to maintain. I think that writing a helper
that enforces the proper pattern is the way to implement this.
i can give it a shot when I have more time (probably in a couple of months), unless
someone else gets to it before me.
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: