Subject Re: [firebird-support] Deadlockdeadlockupdate conflicts with concurrent updatedeadlock Error code 16
Author Helen Borrie
At 03:03 AM 19/10/2004 +0000, you wrote:

>Hi All,
>The environment D7, Intraweb 7.x, kbmMW 1.07e, Embedded Firebird
>1.5.1, UIB dbExpress driver.
>Scenario, a TkbmMWClientStoredProc (client side) which calls
>(Execproc) a named TkbmMWDBXStoredProc procedure on server side. One
>of the parameter is the flag that indicates action of Insert or delete
>a record . The application GUI basically contains two list boxes, the
>user can move items from left to right list box (insert record) or
>from right to left list box (Delete).
>Step 1, user inserts a record and click a button to call the stored
>procedure to insert. Step 2, if the user changes his mind, he moves
>the same item from right to left list box and click a button to call
>the stored procedure to delete. Step 3, if he decides to insert the
>same item again ,by moving the item back to the right list box, if he
>calls the stored procedure for the third time, an error occur with the
>following message:
>"Deadlockdeadlockupdate conflicts with concurrent updatedeadlock Error
>code 16 (100000)". The client application built with Intraweb (GUI in
>browser), the 3 steps mentioned above happened without closing the
>browser, it means same session. If we close the browser and open a new
>browser to initiate a new session, step 1 & 2 can be carried out but
>step 3 will definitely run into similar error.
>I have tried to include commit, resolve after Execute the stored
>procedure, still the error occurs. Was this error message initiated by
>FB engine? Anyway to get rid the updatedeadlock error which happpens
>very frequently?

Error code 16 isn't a FB error code so something in your application layers
is reinterpreting the exceptions coming from the engine. There is some kind
of lock conflict or deadlock occurring, obviously.

Are you an end-user or are you a developer with access to the source code?

There's nothing in your problem description that tells us what transactions
are at play here or how they are configured (isolation, lock resolution
settings, record_version or not if isolation is Read Committed....). Nor
do you indicate whether all this conjuring in the GUI actually causes commits.

More info is needed.