[
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)
