You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 (Exceptionex) {
DataSourceUtils.releaseConnection(con, this.dataSource);
thrownewCannotCreateTransactionException("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 com.microsoft.sqlserver.jdbc.SQLServerConnection@266290d7 is closed.
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()
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.
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 anOutOfMemoryError
occurs we notice that the connections are not released. Here is the code snipped fromdoBegin()
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 :
Affects: 3.2.3
Issue Links:
The text was updated successfully, but these errors were encountered: