I wanted to ask if it is possible for threads using read-only cursor
operations to experience deadlocks in a transaction environment.

In the application I am working with, we have a large number of threads
doing stateless service requests. The threads create transactions, and
use the transactions to create cursors via the Java method
Database.openCursor(txn,null); It then ends up using that cursor to
find data by calling Cursor.getKeySearchRange( with a lock mode of
DB_READ_COMMITTED).

Right now the idea is to minimize the chance of deadlocks because we
have a high total # of thread reading the table. We initially had our
application updating some of the data being read, but got a high
frequence of deadlocks. We removed the updates.

One thing we are still seeing is something odd in the transactional
stats. We are still seeing the aborted transaction count go up, but to
my knowledge the only situation where we would do an abort is from the
TransactionRunner object, in the event that maximum retries is
surpassed (10). Otherwise, I can't explain the increase in aborts.
Does the statistics on transactions include commit and abort activity
not directly related to application transactions? Can an application
using transactional cursors, in a read-only manner still encounter
deadlocks?

Hi Bob,

bob.s.walters (AT) gmail (DOT) com wrote:
operations.

Can an application
This should not happen.

Are you sure you have turned off ALL update activity?

What version of Berkeley DB are you running with?

What OS?

Ron

Hi Ron,

I think I have this figured out. The error we're getting is not
actually a deadlock, it was a lock not granted exception. We're using
the standard BDB product, java api. (The one which is based on JNI.)
The lock not granted exception appears to have been our fault.

One thing that threw us off for a bit was that we "assumed" that the
TransactionRunner would handle both deadlock exceptions and lock not
granted exceptions. So we mis-interpreted lock not granted exceptions
as indicating that a good deal of retry had happened, when in fact it
hadn't.

After clearing up some of the code, we now seem to be deadlock free.