Library Version 12.1.6.0

Chapter 4. Concurrency
Prev |  | Next

## Chapter 4. Concurrency

JE offers a great deal of support for multi-threaded applications even when transactions are not in use. Many of JE's handles are thread-safe and JE provides a flexible locking subsystem for managing databases in a concurrent application. Further, JE provides a robust mechanism for detecting and responding to lock conflicts. All of these concepts are explored in this chapter.

Before continuing, it is useful to define a few terms that will appear throughout this chapter:

- Thread of control

  Refers to a thread that is performing work in your application. Typically, in this book that thread will be performing JE operations.

- Locking

  When a thread of control obtains access to a shared resource, it is said to be locking that resource. Note that JE supports both exclusive and non-exclusive locks. See Locks for more information.

- Free-threaded

  Data structures and objects are free-threaded if they can be shared across threads of control without any explicit locking on the part of the application. Some books, libraries, and programming languages may use the term thread-safe for data structures or objects that have this characteristic. The two terms mean the same thing.

  For a description of free-threaded JE objects, see Which JE Handles are Free-Threaded.

- Blocked

  When a thread cannot obtain a lock because some other thread already holds a lock on that object, the lock attempt is said to be blocked. See Blocks for more information.

- Deadlock

  Occurs when two or more threads of control attempt to access conflicting resource in such a way as none of the threads can any longer make further progress.

  For example, if Thread A is blocked waiting for a resource held by Thread B, while at the same time Thread B is blocked waiting for a resource held by Thread A, then neither thread can make any forward progress. In this situation, Thread A and Thread B are said to be deadlocked.

  For more information, see Deadlocks.

- Lock Conflict

  In JE, a lock conflict simply means that a thread of control attempted to obtain a lock, but was unable to get it before the lock timeout period expired. This may have happened because a deadlock has occurred, or it might have happened because another thread is taking too long to complete a long-running database operation. Either way, you do the same things in response to a lock conflict as you do for a true deadlock. See JE Lock Management for more information.

## Which JE Handles are Free-Threaded

The following describes to what extent and under what conditions individual handles are free-threaded.

- `Environment` and the DPL `EntityStore`

  This class is free-threaded.

- `Database` and the DPL `PrimaryIndex`

  These classes are free-threaded.

- `SecondaryDatabase` and DPL `SecondaryIndex`

  These classes are free-threaded.

- `Cursor` and the DPL `EntityCursor`

  If the cursor is a transactional cursor, it can be used by multiple threads of control so long as the application serializes access to the handle. If the cursor is not a transactional cursor, it can not be shared across multiple threads of control at all.

- `SecondaryCursor`

  Same conditions apply as for `Cursor` handles.

- `Transaction`

  This class is free-threaded.

### Note

All other classes found in the DPL (`com.sleepycat.persist.*`) and not mentioned above are free-threaded.

All classes found in the bind APIs (`com.sleepycat.bind.*`) are free-threaded.

Prev |  | Next
Configuring the Transaction Subsystem | Home | Locks, Blocks, and Deadlocks