Question on why LockMode.READ_UNCOMMITTED is waiting on read locks

Question

Running je-5.0.103
We are running some load tests with multiple threads accessing our BDB. When we take a thread dump in the middle of the test we have noticed several of the threads waiting on a ReadLock even though we are using LockMode.READ_UNCOMMITTED.
The javadoc for LockMode states:
"With one exception, a record lock is always acquired when a record is read or written, and a cursor will always hold the lock as long as it is
positioned on the record.  The exception is when {@link #READ_UNCOMMITTED} is specified, which allows a record to be read without any locking."
Our load test is performing only reads and there should be no writes happening at all.
So the question is why are still acquiring read locks?  Is there some other configuration setting that we have that would override this or is the lock that we see in the thread dump a different lock?
Here is a sample thread waiting for a lock.
"EJB default - 126" prio=10 tid=0x00007f730c05f800 nid=0x5378 waiting on condition [0x00007f72af8c1000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00007f75568b4238> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
        at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:731)
        at com.sleepycat.je.latch.SharedLatch.acquireShared(SharedLatch.java:149)
        at com.sleepycat.je.tree.IN.latchShared(IN.java:497)
        at com.sleepycat.je.tree.Tree.getRootINRootAlreadyLatched(Tree.java:2105)
        at com.sleepycat.je.tree.Tree.getRootINInternal(Tree.java:2087)
        at com.sleepycat.je.tree.Tree.getRootIN(Tree.java:2069)
        at com.sleepycat.je.tree.Tree.search(Tree.java:1237)
        at com.sleepycat.je.dbi.CursorImpl.searchAndPosition(CursorImpl.java:2118)
        at com.sleepycat.je.Cursor.searchInternal(Cursor.java:2822)
        at com.sleepycat.je.Cursor.searchAllowPhantoms(Cursor.java:2732)
        at com.sleepycat.je.Cursor.searchNoDups(Cursor.java:2586)
        at com.sleepycat.je.Cursor.dupsGetSearchKey(Cursor.java:3714)
        at com.sleepycat.je.Cursor.searchHandleDups(Cursor.java:3684)
        at com.sleepycat.je.Cursor.search(Cursor.java:2551)
        - locked <0x00007f74d7801d88> (a com.sleepycat.je.Cursor)
        at com.sleepycat.je.Database.get(Database.java:1294)
        at com.farecompare.atpcore.storageenginemodule.impl.berkeleydb.components.AtpRecordStore.getRecordsNoCursor(AtpRecordStore.java:215)
Our code snippet making the call:
private List<ATPRecord> getRecordsNoCursor( String key, Class<? extends ATPRecord> recordInterface ) throws StorageEngineException {
DatabaseEntry theKey = makeKey( key );
DatabaseEntry foundData = new DatabaseEntry();
List<ATPRecord> records = null;
OperationStatus retVal = getDatabase().get( null, theKey, foundData, LockMode.READ_UNCOMMITTED );   <<<<<< waits here
if ( retVal == OperationStatus.SUCCESS ) {
records = convertToRecordList( foundData.getData(), recordInterface );
else {
records = createRecordList( recordInterface, 0 );
return records;
Thanks,
Chris Stillwell

Answer 1

The call to IN.latchShared you're seeing is not a record lock, it's an internal latch on a Btree node.  Latching is not related to the lock mode.  This latch should be held for a short time, but in cases where many threads access the same records (or a very small set of records), you will see waiting on latches.  You can't disable latching -- thread safety requires it.
--mark