Chapter 6. Summary and Examples

Table of Contents

Anatomy of a Transactional Application
Base API Transaction Example
DPL Transaction Example

Throughout this manual we have presented the concepts and mechanisms that you need to provide transactional protection for your application. In this chapter, we summarize these mechanisms, and we provide a complete example of a multi-threaded transactional JE application.

Anatomy of a Transactional Application

Transactional applications are characterized by performing the following activities:

  1. Create your environment handle.

  2. Open your environment, specifying that the transactional subsystem is to be used.

  3. If you are using the base API, open your database handles, indicating that they are to support transactions. Otherwise, open your store such that it is configured for transactions.

  4. Spawn off worker threads. How many of these you need and how they split their JE workload is entirely up to your application's requirements. However, any worker threads that perform write operations will do the following:

    1. Begin a transaction.

    2. Perform one or more read and write operations.

    3. Commit the transaction if all goes well.

    4. Abort and retry the operation if a deadlock is detected.

    5. Abort the transaction for most other errors.

  5. On application shutdown:

    1. Make sure there are no opened cursors.

    2. Make sure there are no active transactions. Either abort or commit all transactions before shutting down.

    3. Close your databases.

    4. Close your environment.


Robust JE applications should monitor their worker threads to make sure they have not died unexpectedly. If a thread does terminate abnormally, you must shutdown all your worker threads and then run normal recovery (you will have to reopen your environment to do this). This is the only way to clear any resources (such as a lock or a mutex) that the abnormally exiting worker thread might have been holding at the time that it died.

Failure to perform this recovery can cause your still-functioning worker threads to eventually block forever while waiting for a lock that will never be released.

In addition to these activities, which are entirely handled by code within your application, you also need to periodically back up your log files. This is required in order to obtain the durability guarantee made by JE's transaction ACID support. See Backing up and Restoring Berkeley DB, Java Edition Applications for more information.