Subject lock_conflict vs. concurrent_transaction
Author unordained
I'd like to be able to give my users some clue why their requested changes
failed, when a lock is involved. If I catch a 335544878 (current_transaction,
"Concurrent transaction number is @1"), I can extract the transaction # and find
out who the other user (or automated system) was, what the transaction was trying
to do, etc.

But if I get 335544345 (lock_conflict, "Lock conflict on no wait transaction"), I
can't, because the message doesn't contain the transaction #. I've looked at the
chain of sql exceptions I get (jaybird) and it seems that if I attempt to
directly update the record that's locked, I'll get just concurrent_transaction,
but if I try to just insert a related record, I'll get an FK constraint which is
then itself covered up (I don't mean in a bad way) by lock_conflict.

I understand why I get the FK constraint (once a transaction gets a record lock
by updating a record, it could chose to delete the record or change its PK, so no
other transactions are allowed to create new records that reference it) but I'd
like to know if there's any way I could get the opposing transaction #
consistently, regardless of what type of change I try to make.

Does FB return that information to the client at all (i.e. I should ask on
firebird-java about forcing the API to give me the information) or does FB just
return the errors I see (FK + lock)? Is this something being considered for
future improvement?