[#JDBC-386] Changes to transaction configuration of a connection are propagated to **all** connections to the same database

Jaybird JDBC Driver

Changes to transaction configuration of a connection are propagated to all connections to the same database

Created: 21/Mar/15 01:50 PM Updated: Friday 01:04 PM

Component/s:

JDBC driver, XCA/JCA layer

Affects Version/s:

Jaybird 2.2, Jaybird 2.2.1, Jaybird 2.2.2, Jaybird 2.2.3, Jaybird 2.2.4, Jaybird 2.2.5, Jaybird 2.2.6, Jaybird 2.2.7, Jaybird 3.0.5, Jaybird 2.2.15, Jaybird 4.0.0-beta-1, Jaybird 3.0.6, Jaybird 3.0.7, Jaybird 3.0.8, Jaybird 4.0.0-beta-2, Jaybird 4, Jaybird 4.0.0

Fix Version/s:

Jaybird 3.0.9, Jaybird 4.0.1, Jaybird 5

Description

« Hide

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.

All

Comments

Change History

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Mark Rotteveel added a comment - 26/Mar/20 11:47 AM

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

[ Permalink | « Hide ]

Attila Molnár added a comment - 27/Mar/20 07:22 AM

Hi Mark!

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

Thank you!

[ Permalink | « Hide ]

Mark Rotteveel added a comment - 29/Mar/20 02:00 PM

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.

[ Permalink | « Hide ]

Mark Rotteveel added a comment - 29/Mar/20 03:28 PM

Backported to 3.0.9 and 4.0.1

[ Permalink | « Hide ]

Attila Molnár added a comment - 30/Mar/20 06:35 AM

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

[ Permalink | « Hide ]

Mark Rotteveel added a comment - 30/Mar/20 07:43 AM

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