commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DBCP-522) Cached autocommit state can get out of sync with the database if Error is thrown
Date Fri, 02 Nov 2018 16:05:00 GMT

    [ https://issues.apache.org/jira/browse/DBCP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673333#comment-16673333
] 

Gary Gregory commented on DBCP-522:
-----------------------------------

[~wtmitchell3],

Thank you for your report.

Please feel free to propose a PR on GitHub: [https://github.com/apache/commons-dbcp]

Gary

> Cached autocommit state can get out of sync with the database if Error is thrown
> --------------------------------------------------------------------------------
>
>                 Key: DBCP-522
>                 URL: https://issues.apache.org/jira/browse/DBCP-522
>             Project: Commons DBCP
>          Issue Type: Bug
>    Affects Versions: 2.1.1, 2.2.0, 2.3.0, 2.4.0, 2.5.0
>            Reporter: Bill Mitchell
>            Priority: Major
>
> DelegatingConnection.setAutoCommit() resets autoCommitCached to null to indicate if a
SQLException is caught.  This suffices in most cases, but if a Java Error is thrown, e.g.,
OutOfMemoryError, the autoCommitCached state retains its original value, even though the database
might have received and honored the change (the OutOfMemoryError might have happened when
the JDBC driver processed the response).  
> The impact of this on an app that tries to manage and continue after the Error is rather
severe, as the incorrect cached auto commit value means that the rollbackOnReturn and enableAutoCommitOnReturn
options do not cause the connection to be restored to a predictable state, as the Java side
believes the connection is not in a transaction, even though the database server side believes
it is.  
> At least three fixes possible.  One could set autoCommitCached to null before issuing
the request, and then give it a value only if the the database request succeeded.  One could
catch all Throwables, not just SQLException.  One could maintain the new state in a local
initialized to null, and then store its value in a finally block, which would avoid actually
catching and rethrowing a Throwable.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message