Changes to transaction configuration of a connection are propagated to **all** connections to the same database [JDBC386]

[firebird-automations]

Submitted by: @mrotteveel

Changes to the transaction configuration of a connection are propagated to **all** connections to the same database (with identical user and other connection properties).

For example the various FirebirdConnection.setTransactionParameters methods propagate the changes to the ManagedConnectionFactory which is shared for all connections with the same connection properties. This leads to unwanted and unexpected modification of the transaction behavior of other connections. The transaction config should be specific to the ManagedConnection and not be propagated to the ManagedConnectionFactory.

Commits: 70e970f 9d52511 0395ec4 cde96f3

[firebird-automations]

Modified by: @mrotteveel

Version: Jaybird 4.0.0 [ 10903 ]

Version: Jaybird 4 [ 10441 ]

Version: Jaybird 4.0.0-beta-2 [ 10902 ]

Version: Jaybird 3.0.8 [ 10916 ]

Version: Jaybird 3.0.7 [ 10910 ]

Version: Jaybird 3.0.6 [ 10883 ]

Version: Jaybird 4.0.0-beta-1 [ 10901 ]

Version: Jaybird 2.2.15 [ 10860 ]

Version: Jaybird 3.0.5 [ 10873 ]

Fix Version: Jaybird 5 [ 10871 ]

[firebird-automations]

Modified by: @mrotteveel

Link: This issue depends on JDBC618 [ JDBC618 ]

[firebird-automations]

Modified by: @mrotteveel

Link: This issue depends on JDBC618 [ JDBC618 ] =>

[firebird-automations]

Commented by: @mrotteveel

Fixed by copying the mapping configuration on first connection specific change, and using the copy for the remainder of the connection.

[firebird-automations]

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

[firebird-automations]

Commented by: Attila Molnár (e_pluribus_unum)

Hi Mark!

This is a serious issue. It should be backported to 3.x and 4.x series.

Thank you!

[firebird-automations]

Modified by: @mrotteveel

status: Resolved [ 5 ] => Reopened [ 4 ]

resolution: Fixed [ 1 ] =>

[firebird-automations]

Modified by: @mrotteveel

Fix Version: Jaybird 3.0.9 [ 10917 ]

Fix Version: Jaybird 4.0.1 [ 10921 ]

[firebird-automations]

Commented by: @mrotteveel

It is only serious if you actually modify the transaction mapping using FirebirdConnection.setTransactionParameters (or FBManagedConnection.setTransactionParameters). This only concerns modification of transaction configuration (so the DPB mapping of a transaction isolation level), and I think that is hardly ever done. I only found it by inspecting the code. As at that time I couldn't find a simple fix, I left it as is.

However, now I fixed it, the fix turns out to be relatively small, so I'll backport.

[firebird-automations]

Commented by: @mrotteveel

Backported to 3.0.9 and 4.0.1

[firebird-automations]

Modified by: @mrotteveel

status: Reopened [ 4 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

[firebird-automations]

Commented by: Attila Molnár (e_pluribus_unum)

Hi!
Thank you fot the backport.

(PS: How the hell people not use setTransactionParameters? How do they set/change R/W, RC/CONCURRENCY, REC_VERSION, WAIT/NO_WAIT mode on the transaction?)

[firebird-automations]

Commented by: @mrotteveel

Hi Attila, I guess most will use the defaults, or use the available connection properties to specify the transaction configuration on connect instead of later.

And READ COMMITTED vs CONCURRENCY can be handled through setting the isolation level, READ vs WRITE through setReadOnly. To be clear, this problem only affected setTransactionParameters(int, int[]) and setTransactionParameters(int, TransactionParameterBuffer), and not setTransactionParameters(TransactionParameterBuffer).

[firebird-automations]

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]