12:42 p.m.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close both
in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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
11:07 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Dirk Feufel commented on HHH-2455:
----------------------------------
I just noted that this problem also causes another nasty ouput since
batcher.hasOpenResources() falsely returns true there:
"forcing batcher resource cleanup on transaction completion; forgot to close
ScrollableResults/Iterator?"
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Original Estimate: 1 hour
Remaining: 1 hour
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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
12:09 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Florian Probst commented on HHH-2455:
-------------------------------------
We currently have OutOfMemory issues by using the DbTimestampType.seed() Method very
frequently for querying the current database timestamp. This is uesed in a Thread who
never closes his current Session and because a clear() does not clean the opened
ResultSets the memory is never deallocated.
As alread said, calling closeQueryStatement() instead of closeStatement() would solve the
problem.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Original Estimate: 1 hour
Remaining Estimate: 1 hour
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Harald Gliebe commented on HHH-2455:
------------------------------------
This problem still exists in 3.6.4. Here is the patch. Please apply!
diff -u hibernate-core\src\main\java\org\hibernate\type\DbTimestampType.java
DbTimestampType.java
--- hibernate-core\src\main\java\org\hibernate\type\DbTimestampType.java 2011-05-04
14:44:42.000000000 +0200
+++ d:\home\Downloads\DbTimestampType.java 2011-05-20 16:11:20.754870600 +0200
@@ -89,9 +89,10 @@
private Timestamp usePreparedStatement(String timestampSelectString, SessionImplementor
session) {
PreparedStatement ps = null;
+ ResultSet rs = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
- ResultSet rs = session.getBatcher().getResultSet( ps );
+ rs = session.getBatcher().getResultSet( ps );
rs.next();
Timestamp ts = rs.getTimestamp( 1 );
if ( log.isTraceEnabled() ) {
@@ -114,7 +115,7 @@
finally {
if ( ps != null ) {
try {
- session.getBatcher().closeStatement( ps );
+ session.getBatcher().closeQueryStatement( ps, rs );
}
catch( SQLException sqle ) {
log.warn( "unable to clean up prepared statement", sqle );
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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:02 p.m.
New subject: [Hibernate-JIRA] Issue Comment Edited: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Harald Gliebe edited comment on HHH-2455 at 5/20/11 10:00 AM:
--------------------------------------------------------------
This problem still exists in 3.6.4. Here is the patch. Please apply!
{noformat}
diff -u hibernate-core\src\main\java\org\hibernate\type\DbTimestampType.java
DbTimestampType.java
--- hibernate-core\src\main\java\org\hibernate\type\DbTimestampType.java 2011-05-04
14:44:42.000000000 +0200
+++ d:\home\Downloads\DbTimestampType.java 2011-05-20 16:11:20.754870600 +0200
@@ -89,9 +89,10 @@
private Timestamp usePreparedStatement(String timestampSelectString, SessionImplementor
session) {
PreparedStatement ps = null;
+ ResultSet rs = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
- ResultSet rs = session.getBatcher().getResultSet( ps );
+ rs = session.getBatcher().getResultSet( ps );
rs.next();
Timestamp ts = rs.getTimestamp( 1 );
if ( log.isTraceEnabled() ) {
@@ -114,7 +115,7 @@
finally {
if ( ps != null ) {
try {
- session.getBatcher().closeStatement( ps );
+ session.getBatcher().closeQueryStatement( ps, rs );
}
catch( SQLException sqle ) {
log.warn( "unable to clean up prepared statement", sqle );
{noformat}
was (Author: hgliebe):
This problem still exists in 3.6.4. Here is the patch. Please apply!
diff -u hibernate-core\src\main\java\org\hibernate\type\DbTimestampType.java
DbTimestampType.java
--- hibernate-core\src\main\java\org\hibernate\type\DbTimestampType.java 2011-05-04
14:44:42.000000000 +0200
+++ d:\home\Downloads\DbTimestampType.java 2011-05-20 16:11:20.754870600 +0200
@@ -89,9 +89,10 @@
private Timestamp usePreparedStatement(String timestampSelectString, SessionImplementor
session) {
PreparedStatement ps = null;
+ ResultSet rs = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
- ResultSet rs = session.getBatcher().getResultSet( ps );
+ rs = session.getBatcher().getResultSet( ps );
rs.next();
Timestamp ts = rs.getTimestamp( 1 );
if ( log.isTraceEnabled() ) {
@@ -114,7 +115,7 @@
finally {
if ( ps != null ) {
try {
- session.getBatcher().closeStatement( ps );
+ session.getBatcher().closeQueryStatement( ps, rs );
}
catch( SQLException sqle ) {
log.warn( "unable to clean up prepared statement", sqle );
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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:04 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Harald Gliebe updated HHH-2455:
-------------------------------
Attachment: patch-for-3.6.4.patch
Patch for hibernate-core 3.6.4
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
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:30 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Steve Ebersole commented on HHH-2455:
-------------------------------------
Can you verify whether this happens with 4.0?
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:44 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Dirk Feufel commented on HHH-2455:
----------------------------------
The warning output should no longer happen in 4.0 since the DbTimestamp class now closes
the PreparedStatement directly via close and does not use the Batcher methods which no
longer exists. But the DbTimestamp class still does not call close on the ResultSet in
4.0. So the problem reported by Florian Probst still exists. So similar cleanup code for
the ResultSet should be applied in 4.0 as well.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:43 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Steve Ebersole commented on HHH-2455:
-------------------------------------
Have you actually verified that? The way JDBC resource registration and cleanup happen in
4.0 is very different.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:59 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Dirk Feufel commented on HHH-2455:
----------------------------------
I have taken a look at the source for both 3.6.4 and 4.0.0 and noted that the cleanup
indead has changed. In 4.0 the cleanup must be performed locally in
DbTimestampType#usePreparedStatement, in 3.6 the usePreparedStatement must call
closeQueryStatement instead of closeStatement. Since the ResultSet is a local variable in
4.0 code I cannot see how any other code could do a cleanup. This should be a plain JDBC
api topic only.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:20 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Steve Ebersole commented on HHH-2455:
-------------------------------------
Why does this have to be so difficult? Try it. Does it still happen in 4.0?
The code has significantly changed as I already said and as you said you have already
seen. If you had dug a little deeper you would have seen that Hibernate proxies all JDBC
resources. Which lets it do many things, specifically 2 of which can be seen in this
case:
# when a {{ResultSet}} is opened from a {{Statement}}, register that {{ResultSet}} against
that {{Statement}}.
# when {{Statement}} is closed, because of the above, we know all the {{ResultSet}} that
need to be closed.
So please, when we ask you to verify something please just try to verify it. You sitting
here arguing about how its "probably still a problem" serves no purpose.
See {{org.hibernate.engine.jdbc.spi.JdbcResourceRegistry}} and the
{{org.hibernate.engine.jdbc.internal.proxy}} package if you are interested in the details
of how this all works
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:25 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Steve Ebersole commented on HHH-2455:
-------------------------------------
Note also, that JDBC itself says that drivers should do this clean up of result sets when
a statement is closed. Let's be nice and say that some drivers do a better job of
this than others.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:56 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Dirk Feufel commented on HHH-2455:
----------------------------------
The problem is how I should prove that the problem still exists in 4.0. The warning
message will no longer be shown. And I could hardly write a test case that determines if
the driver left some cursor or whatever open when the ResultSet is not closed correctly.
But what I can say is that in 3.6.4 the problem still exists and can be fixed by the
provided patch. I currently do not have a 4.0 environment ready to test this issue. But
the common style (even in the 4.0 hibernate code) is:
ResultSet rs = st.executeQuery();
try {
// do something with the ResultSet
} finally {
rs.close();
}
Even if the close is a NOP I think it is cleaner code if it is called.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:23 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Steve Ebersole resolved HHH-2455.
---------------------------------
Resolution: Out of Date
No longer an issue in 4.0
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:23 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Steve Ebersole commented on HHH-2455:
-------------------------------------
Dirk, well we will have to agree to disagree. I think it is far cleaner to expect that
when i close a resource it should close its child resources. And as I pointed out, JDBC
requires this, albeit in a limited fashion.
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:07 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Dirk Feufel commented on HHH-2455:
----------------------------------
I agree with you that it is cleaner if all associated resources are closed. If we can be
sure about that (via the proxied Statement) thats fine. But what's about the 3.6.x
release? Are there no further maintenance releases planned?
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:22 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Florian Probst updated HHH-2455:
--------------------------------
Attachment: hibernate4-test.zip
Test with hibernate-core 4.0
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: hibernate4-test.zip, patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:28 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2455) "Could not close a JDBC result set" output very often
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455?page=c...
]
Florian Probst commented on HHH-2455:
-------------------------------------
I created a unit test using hibernate4 (see attachment). This test case calls frequently
the DbTimestamp.seed() method and the memory usage seems to be constant. The test case
came with a H2 database, but I ran it also against a Oracle 11g database with the same
result.
Currently we are not planning to switch to hibernate 4 so a patch of the current 3.6.x
series would be nice!
"Could not close a JDBC result set" output very often
-----------------------------------------------------
Key: HHH-2455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Reporter: Dirk Feufel
Priority: Minor
Attachments: hibernate4-test.zip, patch-for-3.6.4.patch
Original Estimate: 1h
Remaining Estimate: 1h
If you call this type of code (like the DbTimestampType class does), the AbstractBatcher
outputs a warning "Could not close a JDBC result set".
The problem should be that closing the prepared statement internally also closes the
associated result sets and the AbstractBatcher still has a reference to this result set.
One possible solution might be to provide an additional method
public void closeStatement(PreparedStatement ps, ResultSet rs);
(as already present for closeQueryStatement) in the AbstractBatcher allowing to close
both in the right order.
PreparedStatement ps = null;
try {
ps = session.getBatcher().prepareStatement( timestampSelectString );
ResultSet rs = session.getBatcher().getResultSet( ps );
....
} finally {
if ( ps != null ) {
session.getBatcher().closeStatement( ps );
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4497
days inactive
6274
days old
hibernate-issues@lists.jboss.org
17 comments
4 participants
participants (4)
-
Dirk Feufel (JIRA) -
Florian Probst (JIRA)
-
Harald Gliebe (JIRA)
-
Steve Ebersole (JIRA)