Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JDBC Connection is not released due to incorrectly defined catch [SPR-10755] #15381

spring-issuemaster opened this issue Jul 18, 2013 · 3 comments


None yet
2 participants
Copy link

commented Jul 18, 2013

Peter Szanto opened SPR-10755 and commented

DataSourceTransactionManager contains a bug when releasing the connection. According to the official recommendation, The problem here is that the code only releases the connection when an exception occurs, not when an Error. In our case when an OutOfMemoryError occurs we notice that the connections are not released. Here is the code snipped from doBegin()

try {

catch (Exception ex) {
	DataSourceUtils.releaseConnection(con, this.dataSource);
	throw new CannotCreateTransactionException("Could not open JDBC Connection for transaction", ex);

The problem is that OOM can be recovered, but not releasing the connections cannot be recovered.

Not sure how much it is related, but when I see abandoned JDBC connections I also see these in the log file :

org.springframework.transaction.TransactionSystemException: Could not roll back JDBC transaction; nested exception is java.sql.SQLException: Connection is closed.

Affects: 3.2.3

Issue Links:

  • #16885 DataSourceTransactionManager closes JDBC connection on doBegin failure but leaves it attached to transaction object

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 22, 2013

Phil Webb commented

The Error exception is generally not considered recoverable, from the Error Javadoc:

An Error is a subclass of Throwable
that indicates serious problems that a reasonable application
should not try to catch

Do you know the underlying cause of the OutOfMemoryError and how are you planning to recover from them?


This comment has been minimized.

Copy link
Collaborator Author

commented Jul 22, 2013

Peter Szanto commented

I agree, in general error is not recoverable, but in our case what I notice is that my application becomes totally unresponsive all threads are blocked waiting for the Connection pool to assign an available connection. When I look into the log file I can see that earlier thee were OutOfMemoryError although I havent yet found the reason for that. My application runs in Tomcat 7, after adding the removeAbandoned="true" parameter to the DBCP config the application seems to work. It still has occassional OOM which is clearly a sign of problem with the application itself, but still it can recover from that, and also tomcat can reclaim the abandoned connections. I also added the logAbandoned="true" option that logs which code abandoned the connection and it is clearly DataSourceTransactionManager.doBegin()


This comment has been minimized.

Copy link
Collaborator Author

commented Jul 24, 2013

Juergen Hoeller commented

Even if an OutOfMemoryError coming out of transaction infrastructure code doesn't feel very recoverable - in contrast to an OOME originating in user code, like within a transaction -, there doesn't seem to be a disadvantage to code defensively there. As a consequence, we're catching Throwable in all doBegin sections of our resource-based TransactionManager implementations now.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.