You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)?
Vlad:
The later - one of lock errors as primary error code and isc_foreign_key as secondary.
[copied from firebird-devel list]
The text was updated successfully, but these errors were encountered:
Would it be possible to extend both 335544345 (above) and 335544336 (deadlock)? I could see that one being harder, as the deadlock graph may involve multiple conflicting tx numbers and it'd have to pick one?
Another solution, I suppose, would be for 335544838 to return information about which FK or remote table was at fault, so the client could fail and make its own update attempt to get the 335544878 desired. That seems messier, though I don't suppose it would hurt for the FK error to return extra info, someone else might have a use for it...
It`s look like in case of lock_conflict in trigger or stored procedure secondary error code is replaced by 335544842 (stack_trace), so information about lock conflict cause get lost.
Submitted by: Philip Williams (unordained)
Votes: 1
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)?
Vlad:
The later - one of lock errors as primary error code and isc_foreign_key as secondary.
[copied from firebird-devel list]
The text was updated successfully, but these errors were encountered: