.
contact contact

When I use DBLOCK/DBUNLOCK inside a transaction a deadlock happens

 
.
 

Title: When I use DBLOCK/DBUNLOCK inside a transaction a deadlock happens
Document: 953293001
Author: Roland Genske <rhg@marxmeier.com>
Keywords: FAQ,A0600,Database,eloqdb6,Transaction,Deadlock,DBLOCK,DBUNLOCK


Q: Whenever I use DBLOCK/DBUNLOCK inside a transaction a deadlock happens as soon as a second session executes the same program. Is this normal?

A: Unfortunately, it is as long as you introduce transactions without redesigning your DBLOCK strategy. The problem which happens is:

  1. As soon as session 1 updates any record inside a transaction, this record gets locked implicitely until the transaction is committed or rolled-back.

  2. Now, session 2 does a DBLOCK and DBUPDATE. This DBUPDATE blocks because the affected record was previously updated by session 1 and session 1 has not yet committed its transaction. As a consequence, session 2 does not get the chance to DBUNLOCK.

  3. Next, session 1 does a DBLOCK and blocks because session 2 did not yet DBUNLOCK --> a deadlock occurs.
This can be worked-around in your application if you do all relevant DBLOCKs *before* you DBBEGIN the transaction. You might also consider that any DBLOCK is not necessary anymore since the transaction itself provides its own locking (see above). This depends on your application.

A solution to this problem is available with Eloquence A.06.30: With the A.06.30 eloqdb6 database server, any DBUNLOCK inside a transaction is delayed until the transaction is committed or rolled-back. In the example above, this would cause the first DBLOCK in session 2 to block until session 1 commits its transaction.

 
 
.
 
 
  Privacy | Webmaster | Terms of use | Impressum Revision:   
  Copyright © 1995-2002 Marxmeier Software AG