Issue Details (XML | Word | Printable)

Key: JDBC-386
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Mark Rotteveel
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
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: 22/May/20 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: Descending order - Click to sort in ascending order
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).

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

Mark Rotteveel added a comment - 29/Mar/20 03:28 PM
Backported to 3.0.9 and 4.0.1

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.

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!

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.