[Hibernate-JIRA] Created: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
7:13 p.m.
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.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.2-4sp1, Oracle 10g (Oracle9Dialect)
Reporter: Michael Werle
Attachments: generated-lazy-statement-leak.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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:42 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Gail Badner updated HHH-2627:
-----------------------------
Attachment: HHH-2627-testcase.patch
I am attaching a patch that reproduces this issue when processing generated properties and
when initializing lazy properties when it is run using Oracle 10g with a default
installation.
The patch will execute the code in
org.hibernate.test/generated.AbstractGeneratedPropertyTest.testGeneratedProperty() 500
times which causes TriggerGeneratedValuesWithCachingTest and
TriggerGeneratedValuesWithoutCachingTest to fail due to
org.hibernate.exception.GenericJDBCException, caused by java.sql.SQLException: ORA-01000:
maximum open cursors exceeded.
It also executes the code in org.hibernate.test.instrument.cases.TestLazyExecutable 100
times which fails with the same exception.
The number of loops may need to be adjusted depending on the how Oracle is configured.
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-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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:33 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Gail Badner updated HHH-2627:
-----------------------------
Attachment: HHH-2627-SharedPKOneToOne.patch
While reviewing generated-lazy-statement-leak.patch, I noticed there was special code in
AbstractEntityPersister.initializeLazyPropertiesFromDatastore() for the case that the only
lazy property is a shared PK one-to-one association.
I was concerned that a null ResultSet passed to lazyPropertyTypes[j].nullSafeGet() could
result in a NullPointerException. I didn't see any unit tests that covered this case,
so I created org.hibernate.test.instrument.cases.TestSharedPKOneToOneExecutable (and
related classes) to test shared PK one-to-one associations; one with
lazy="proxy" and and one with lazy="no-proxy".
The test succeeds.
I'm attaching a patch for this new test in case you'd like to add it to the test
suite.
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-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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:54 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Willem Voogd updated HHH-2627:
------------------------------
Attachment: HHH-2627-AbstractBatcher_prepareSelectStatement.patch
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:54 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Willem Voogd commented on HHH-2627:
-----------------------------------
I think the problem lies in AbstractBatcher.prepareSelectStatement. The HashSet
statementsToClose should be populated there but is doesnt. So i made a patch in which
prepareSelectStatement just calls prepareQueryStatement (what's the difference between
query and select anyway?).
The patch is made on a local copy of the hibernate src, so revision info is useless, i
don't know whether that's a problem, if so, then just tell me how to make proper
patches for future cases...
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:13 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Michael Werle commented on HHH-2627:
------------------------------------
I tried solving the issue by doing this, also. IIRC, it won't wok becuase several
other places use AbstractBatcher.prepareSelectStatement w/o closing the conneciton with
AbstractBatcher so the count is properly reduced; every one of these other instances would
need to be updated at the same time. I don't remember for sure, but I think that this
change caused some exsisting tests to fail, also.
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:27 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:27 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:17 p.m.
New subject: [Hibernate-JIRA] Assigned: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Gail Badner reassigned HHH-2627:
--------------------------------
Assignee: Gail Badner
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:03 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:38 p.m.
New subject: [Hibernate-JIRA] Closed: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Gail Badner closed HHH-2627.
----------------------------
Resolution: Fixed
Fix Version/s: 3.3
3.2.6
Sorry, I don't know of a workaround for this issue.
Fixed in trunk / 3.2 .
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
Fix For: 3.2.6, 3.3
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:41 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Diego Pires Plentz commented on HHH-2627:
-----------------------------------------
Gail, could you take a look at HHH-2200 to see if it fix this issue too?
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
Fix For: 3.2.6, 3.3
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:01 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Gail Badner commented on HHH-2627:
----------------------------------
Diego, HHH-2200 will be fixed by the fix for this issue also. I've just closed
HHH-2200. Thanks for linking the two issues.
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
Fix For: 3.2.6, 3.3
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:19 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Birger Zimmermann commented on HHH-2627:
----------------------------------------
Today, i mentioned that this bug seems to be present also in hibernate annotations
3.3.0.ga, with hibernate core 3.2.5.ga
In my scenario i insert many rows (> 100000) to a mysql databse which has a trigger on
insert to create a md5.
I sequently commit the transaction, close and clear the session - like described for batch
processing. After around 20000 inserts an out of memory exception occur. The soulution i
found was to remove the @Generated annotation from my entity. Heap analysis with jhat
showed the same phenomen described earlier, around 20000 open prepared statements with
resultssets never closed. Because this Bug is marked for 3.2.3, 3.2.4, 3.2.4.sp1i like to
tell you, it seams also present in my version combination.
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
Fix For: 3.2.6, 3.3
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627?page=c...
]
Diego Pires Plentz commented on HHH-2627:
-----------------------------------------
Birger, it *affects* 3.2.3, 3.2.4, 3.2.4.sp1(and 3.2.5 too, since the fix Version/s are
3.3, 3.2.6) of hibernate core ;-)
PS: is a bug with hibernate core, not with hibernate annotations.
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
Fix For: 3.2.6, 3.3
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6139
days inactive
6340
days old
hibernate-issues@lists.jboss.org
14 comments
6 participants
participants (6)
-
Birger Zimmermann (JIRA) -
Diego Pires Plentz (JIRA)
-
Gail Badner (JIRA)
-
Michael Werle (JIRA)
-
Rafael Chaves (JIRA)
-
Willem Voogd (JIRA)