Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide concurrent transaction number in all lock conflict scenarios [CORE3088] #3467

Open
firebird-automations opened this issue Jul 29, 2010 · 4 comments

Comments

@firebird-automations
Copy link
Collaborator

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]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Philip Williams (unordained)

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...

@firebird-automations
Copy link
Collaborator Author

Commented by: Yurij (yurij)

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I'd say it's unlikely, stack trace is always appended to the existing status vector. So a test case is required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants