Chapter 4. Concurrency

Table of Contents

Which JE Handles are Free-Threaded
Locks, Blocks, and Deadlocks
JE Lock Management
Managing JE Lock Timeouts
Managing Deadlocks and other Lock Conflicts
Supported Degrees of Isolation
Reading Uncommitted Data
Committed Reads
Configuring Serializable Isolation
Transactional Cursors and Concurrent Applications
Using Cursors with Uncommitted Data

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:

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.


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.