Issue Details (XML | Word | Printable)

Key: CORE-6139
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Pavel Zotov
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Regression: can not obtain list of transactions in limbo state when use API

Created: 11/Sep/19 01:23 PM   Updated: 11/Sep/19 05:27 PM
Component/s: API / Client Library, Engine, SVCMGR
Affects Version/s: 3.0.4, 4.0 Beta 1
Fix Version/s: None

File Attachments: 1. Zip Archive make-limbo-transactions.py.zip (2 kB)


QA Status: No test


 Description  « Hide
If database has transaction in limbo state then its ID can be seen only using gfix -list <dbname> command.
API call does not return any ID.
FB 3.x and 4.x are affeted; no such problem in FB 2.5.x.

To reproduce:
1) install Python 2.7 or higher
2) install FDB driver for access to FB databases from Python
3) Unpack attached .zip and open .py script in editor.
4) Adjust following variables from this script to our environment:
=======
DBPATH=r'C:\TEMP'
DBUSER='SYSDBA'
DBPSWD='masterkey'
DBNAME_A = DBPATH + r'\c5930_a.fdb' # name of 1st database
DBNAME_B = DBPATH + r'\c5930_b.fdb' # name of 2nd database
LIMBO_COUNT = 3 # how many limbo transactions we want to have as result in 1st database.
=======

To run this script you must specify full path and name of client library as 1st (and single) parameter.

Examples (for Windows; check FB 2.5, 3.0 and 4.0 respectively):

python make-limbo-transactions.py C:\FB\25SC\bin\fbclient.dll
python make-limbo-transactions.py C:\FB\30SS\fbclient.dll
python make-limbo-transactions.py C:\FB\40SS\fbclient.dll

This script creates two databases, opens two attachments to each of them, starts transactions in these attachments and use 2PC mechanism for corntrol.
Also, this script launches additional connection to services in order to have ability to change DB state to full shutdown and after this - return DB to online state.

Transaction that operates with DBNAME_B is prepared and committed.
Transaction that operates with DBNAME_A is prepared but after this additional attachment to FB services changes DB to full shutdown.

This lead DBNAME_A to have started transaction(s) in limbo state.
After this, we return DBNAME_A to online and:
1) obtain list of limbo transactions using API call ( get_limbo_transaction_ids );
2) obtain list of limbo transactions using external call to gfix utility ("gfix -list ....")

Expected result: these lists must be equal.
Actual resultL:
1) in FB 2.5: OK, as expected
2) in FB 3.x and 4.x: API call does not return anything. List of transactions remains empty:


These is output:

1) for FB 2.5:

C:\FBTESTING\qa\misc>python make-limbo-transactions.py C:\FB\25sC\bin\fbclient.dll
fdb version: 2.0.0
WI-V2.5.9.27142 Firebird 2.5
Database C:\TEMP\c5930_a.fdb is in full shutdown state now.
ConnectionGroup instance has been cleared.
Database C:\TEMP\c5930_a.fdb is in ONLINE state now.
Trying to get list of limbo Tx.
len(limbo_tx)= 3
--------- start data from get_limbo_transaction_ids -----------
Found Tx in limbo, ID: 3
Found Tx in limbo, ID: 4
Found Tx in limbo, ID: 5
--------- finish data from get_limbo_transaction_ids -----------

Result of C:\FB\25sC\bin\gfix -list C:\TEMP\c5930_a.fdb :
--------- start gfix output -----------
Transaction 3 is in limbo.
Transaction 4 is in limbo.
Transaction 5 is in limbo.
---------- finish gfix output ---------

Bye-bye from Python.


2) for FB 3.0.5:

C:\FBTESTING\qa\misc>python make-limbo-transactions.py C:\FB\30ss\fbclient.dll
fdb version: 2.0.0
WI-V3.0.5.33168 Firebird 3.0
Database C:\TEMP\c5930_a.fdb is in full shutdown state now.
ConnectionGroup instance has been cleared.
Database C:\TEMP\c5930_a.fdb is in ONLINE state now.
Trying to get list of limbo Tx.
len(limbo_tx)= 0
--------- start data from get_limbo_transaction_ids -----------
--------- finish data from get_limbo_transaction_ids -----------

Result of C:\FB\30ss\gfix -list C:\TEMP\c5930_a.fdb :
--------- start gfix output -----------
Transaction 4 is in limbo.
Transaction 5 is in limbo.
Transaction 6 is in limbo.
---------- finish gfix output ---------

Bye-bye from Python.




 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 11/Sep/19 01:43 PM - edited
There is no "get_limbo_transaction_ids" routine in ISC API.
gfix seems to work correctly.
So, i don't see a problem at Firebird side.
Looks like Pyton API shoud be fixed. Probably it is related with 64-bit transaction ID's.

Mark Rotteveel added a comment - 11/Sep/19 03:18 PM
@Vlad I think Pavel means isc_spb_rpr_list_limbo_trans

Vlad Khorsun added a comment - 11/Sep/19 03:46 PM
Ok, there is isc_database_info(, isc_info_limbo) that I forget about.
Anyway, gfix works.
Also, isql's "show database" should enlist in-limbo transactions.

Vlad Khorsun added a comment - 11/Sep/19 05:27 PM
Seems i found the problem.

Pyton call isc_service_query with isc_info_svc_line option.

This is not correct as isc_info_svc_limbo_trans is binary request, also for isc_info_svc_line Firebird replaces "new line" character (\n or 0x10) with space,
see below (sample from CORE-6140, with FB2.5 running):

Found Tx in limbo, ID: 8
Found Tx in limbo, ID: 9
Found Tx in limbo, ID: 32 <<<<< here
Found Tx in limbo, ID: 11
Found Tx in limbo, ID: 12

Instead, isc_info_svc_to_eof (or isc_info_svc_limbo_trans) should be used.