Subject | Re: [Firebird-Java] A fix for JDBC-362 |
---|---|
Author | Mark Rotteveel |
Post date | 2014-09-21T16:13:10Z |
On 21-9-2014 14:02, doychin@... [Firebird-Java] wrote:
distributed transaction it reported autoCommit is true, which is
incorrect. Although in a sense a distributed connection is committed
automatically, it does not come with the implications of autoCommit as
defined in JDBC.
This piece of code however still relied on autoCommit being true in a
distributed transaction.
when making the changes. The above code only works 'by accident' as the
txCoordinator.rollback() does nothing when in a distributed transaction.
The code below is better.
===================================================================
--- src/main/org/firebirdsql/jdbc/AbstractConnection.java (revision 59380)
+++ src/main/org/firebirdsql/jdbc/AbstractConnection.java (revision )
@@ -558,7 +558,7 @@
// leave managed transactions alone, they are normally
// committed after the Connection handle is closed.
- if (!getAutoCommit() &&
getLocalTransaction().inTransaction()) {
+ if (!mc.inDistributedTransaction() &&
!getAutoCommit() && getLocalTransaction().inTransaction()) {
// autocommit is always true for managed tx.
try {
txCoordinator.rollback();
It also looks like I need to review the tests for the JCA resource
adapter specific parts as this wasn't caught in the unit tests nor in
other tests.
Mark
--
Mark Rotteveel
> From what I understand the bheaviour of the jaybird prior 2.2.0 wasNot exactly, in Jaybird 2.1 and earlier, when the connections was in a
> incorrect when it is used in distributed environment.
> setAutoCommit(true) does not fail in jaybird 2.1.x and it replaces
> current transaction coordinator with autocommit version.
distributed transaction it reported autoCommit is true, which is
incorrect. Although in a sense a distributed connection is committed
automatically, it does not come with the implications of autoCommit as
defined in JDBC.
This piece of code however still relied on autoCommit being true in a
distributed transaction.
> I made this patch for 2.2.5 where I test additionally before callingI still need to take examine this further to see if I missed other areas
> setAutoCommit9true) and do not call it when in distributed environment.
> Transaction coordinator is already set to managed versions in setManaged
> so nothing else should happen here.
>
> This changed worked in my test case but I'm not sure it is 100% correct
> so please let me know if there is more to be considered here for this
> problem.
>
> Index: AbstractConnection.java
> ===================================================================
> --- AbstractConnection.java (revision 60051)
> +++ AbstractConnection.java (working copy)
> @@ -563,7 +563,9 @@
> &nbs p; try {
> txCoordinator.rollback();
> } finally {
> - setAutoCommit(true);
> + if (!mc.inDistributedTransaction()) {
> + &n bsp; setAutoCommit(true);
> + }
> }
> }
when making the changes. The above code only works 'by accident' as the
txCoordinator.rollback() does nothing when in a distributed transaction.
The code below is better.
===================================================================
--- src/main/org/firebirdsql/jdbc/AbstractConnection.java (revision 59380)
+++ src/main/org/firebirdsql/jdbc/AbstractConnection.java (revision )
@@ -558,7 +558,7 @@
// leave managed transactions alone, they are normally
// committed after the Connection handle is closed.
- if (!getAutoCommit() &&
getLocalTransaction().inTransaction()) {
+ if (!mc.inDistributedTransaction() &&
!getAutoCommit() && getLocalTransaction().inTransaction()) {
// autocommit is always true for managed tx.
try {
txCoordinator.rollback();
It also looks like I need to review the tests for the JCA resource
adapter specific parts as this wasn't caught in the unit tests nor in
other tests.
Mark
--
Mark Rotteveel