Issue Details (XML | Word | Printable)

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

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

Incorrect limbo transaction numbers

Created: 12/Aug/12 06:28 PM   Updated: 21/Feb/13 08:08 PM
Component/s: Services API
Affects Version/s: Jaybird 2.1.6, Jaybird 2.2
Fix Version/s: Jaybird 2.2.2, Jaybird 3.0

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified

Sub-Tasks  All   Open   

 Description  « Hide
The code below:

FBMaintenanceManager mm = new FBMaintenanceManager("PURE_JAVA");
mm.setHost("xxxx");
mm.setPort(3050);
mm.setDatabase("xxxx");
mm.setUser("sysdba");
mm.setPassword("xxxx");
mm.setLogger(System.out);
mm.listLimboTransactions();

produces this output:

1089469460

While the command below, executed in the same database:

gfix -list xxxx:xxxx -user sysdba -pass xxxx

produces this output:

Transaction 4255740 is in limbo.
Multidatabase transaction:
Host Site: REPLIC-ES
Transaction 4255740
has been prepared.
Remote Site: <removed>
Database Path: <removed>
Host Site: REPLIC-ES
Transaction 4966552
has been rolled back.
Remote Site: <removed>
Database Path: <removed>
Automated recovery would rollback this transaction.

Note that transaction numbers are different...

This is probably an hex conversion problem.

The number returned by jaybird (1089469460) in hex is 40EFFC14.
The number returned by gfix (4255740) in hex is 40EFFC.

So i presume jaybird is taking an extra byte from somewhere.

Fabiano

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Roman Rokytskyy added a comment - 12/Aug/12 06:36 PM
Which FB version do you use? The transaction number is decoded directly from the internal format stored in the database, so most likely the format was changed between the versions...

fabianobonin added a comment - 12/Aug/12 07:27 PM
Using Firebird 2.5.1 here.

I presume Jaybird retrives the transaction number decoding RDB$TRANSACTIONS.RDB$TRANSACTION_DESCRIPTION.
Why is it doing that instead of taking it from RDB$TRANSACTIONS.RDB$TRANSACTION_ID?

Mark Rotteveel added a comment - 14/Aug/12 05:18 PM
Jaybird retrieves this from the servicemanager, it does not query the RDB$TRANSACTIONS table.

I looked at the code and I do think the way it is decoding looks a bit weird:
- It will always restart a decode if it reads 0x13 (isc_spb_single_tra_id),
- it uses 0x00 as an end of transaction_id marker, which doesn't seem to be correct
- and as 0x14 is also isc_spb_multi_tra_id I suspect it is starting to read the next transaction info block.

It also looks like it is only capable of reading single transactions, not multi database transactions.

Mark Rotteveel added a comment - 15/Sep/12 06:14 PM
Removed Jaybird 2.2.1 from fix versions, essentially this has always been broken.

Mark Rotteveel added a comment - 17/Nov/12 01:02 PM
Committed fix to trunk, I would like to add a test that covers multi-site transactions, but I haven't found a way (yet) to create those using Jaybird. For now all existing tests pass.

Mark Rotteveel added a comment - 17/Nov/12 01:03 PM
To do: backport fix to Jaybird 2.2.2

Mark Rotteveel added a comment - 17/Nov/12 01:24 PM
Committed backport to 2.2 branch.

Mark Rotteveel added a comment - 23/Nov/12 11:27 AM
Resolved, created subtask to add multi-site transactions to tests