Chapter 3. Transaction Basics
Prev |  | Next

## Chapter 3. Transaction Basics

Once you have enabled transactions for your environment and your databases, you can use them to protect your database operations. You do this by acquiring a transaction handle and then using that handle for any database operation that you want to participate in that transaction.

You obtain a transaction handle using the `Environment.beginTransaction()` method.

Once you have completed all of the operations that you want to include in the transaction, you must commit the transaction using the `Transaction.commit()` method.

If, for any reason, you want to abandon the transaction, you abort it using `Transaction.abort()`.

Any transaction handle that has been committed or aborted can no longer be used by your application.

Finally, you must make sure that all transaction handles are either committed or aborted before closing your databases and environment.

### Note

If you only want to transaction protect a single database write operation, you can use auto commit to perform the transaction administration. When you use auto commit, you do not need an explicit transaction handle. See Auto Commit for more information.

For example, the following example opens a transactional-enabled environment and store, obtains a transaction handle, and then performs a write operation under its protection. In the event of any failure in the write operation, the transaction is aborted and the store is left in a state as if no operations had ever been attempted in the first place.

    package persist.txn;

    import com.sleepycat.je.DatabaseException;
    import com.sleepycat.je.Environment;
    import com.sleepycat.je.EnvironmentConfig;
    import com.sleepycat.je.Transaction;

    import com.sleepycat.persist.EntityStore;
    import com.sleepycat.persist.StoreConfig;

    import java.io.File;

    ...

    Environment myEnv = null;
    EntityStore store = null;

    // Our convenience data accessor class, used for easy access to
    // EntityClass indexes.
    DataAccessor da;

    try {
        EnvironmentConfig myEnvConfig = new EnvironmentConfig();
        myEnvConfig.setTransactional(true);
        myEnv = new Environment(new File("/my/env/home"),
                                  myEnvConfig);

        StoreConfig storeConfig = new StoreConfig();
        storeConfig.setTransactional(true);

        EntityStore store = new EntityStore(myEnv,
                                 "EntityStore", storeConfig);

        da = new DataAccessor(store);

        // Assume that Inventory is an entity class.
        Inventory theInventory = new Inventory();
        theInventory.setItemName("Waffles");
        theInventory.setItemSku("waf23rbni");

        Transaction txn = myEnv.beginTransaction(null, null);

        try {
            // Put the object to the store using the transaction handle.
            da.inventoryBySku.put(txn, theInventory);

            // Commit the transaction. The data is now safely written to the
            // store.
            txn.commit();
        // If there is a problem, abort the transaction
        } catch (Exception e) {
            if (txn != null) {
                txn.abort();
                txn = null;
            }
        }

    } catch (DatabaseException de) {
        // Exception handling goes here
    }

The same thing can be done with the base API; the database in use is left unchanged if the write operation fails:

    package je.txn;

    import com.sleepycat.je.Database;
    import com.sleepycat.je.DatabaseConfig;
    import com.sleepycat.je.DatabaseEntry;
    import com.sleepycat.je.DatabaseException;
    import com.sleepycat.je.Environment;
    import com.sleepycat.je.EnvironmentConfig;
    import com.sleepycat.je.Transaction;

    import java.io.File;

    ...

    Database myDatabase = null;
    Environment myEnv = null;
    try {
        EnvironmentConfig myEnvConfig = new EnvironmentConfig();
        myEnvConfig.setTransactional(true);
        myEnv = new Environment(new File("/my/env/home"),
                                  myEnvConfig);

        // Open the database. Create it if it does not already exist.
        DatabaseConfig dbConfig = new DatabaseConfig();
        dbConfig.setTransactional(true);
        myDatabase = myEnv.openDatabase(null,
                                        "sampleDatabase",
                                        dbConfig);

        String keyString = "thekey";
        String dataString = "thedata";
        DatabaseEntry key =
            new DatabaseEntry(keyString.getBytes("UTF-8"));
        DatabaseEntry data =
            new DatabaseEntry(dataString.getBytes("UTF-8"));

        Transaction txn = myEnv.beginTransaction(null, null);

        try {
            myDatabase.put(txn, key, data);
            txn.commit();
        } catch (Exception e) {
            if (txn != null) {
                txn.abort();
                txn = null;
            }
        }

    } catch (DatabaseException de) {
        // Exception handling goes here
    }

## Committing a Transaction

In order to fully understand what is happening when you commit a transaction, you must first understand a little about what JE is doing with its log files. Logging causes all database or store write operations to be identified in log files (remember that in JE, your log files are your database files; there is no difference between the two). Enough information is written to restore your entire BTree in the event of a system or application failure, so by performing logging, JE ensures the integrity of your data.

Remember that all write activity made to your database or store is identified in JE's logs as the writes are performed by your application. However, JE maintains logs in memory. Eventually this information is written to disk, but especially in the case of a transactional application this data may be held in memory until the transaction is committed, or JE runs out of buffer space for the logging information.

When you commit a transaction, the following occurs:

- A commit record is written to the log. This indicates that the modifications made by the transaction are now permanent. By default, this write is performed synchronously to disk so the commit record arrives in the log files before any other actions are taken.

- Any log information held in memory is (by default) synchronously written to disk. Note that this requirement can be relaxed, depending on the type of commit you perform. See Non-Durable Transactions for more information.

  Note that a transaction commit only writes the BTree's leaf nodes to JE's log files. All other internal BTree structures are left unwritten.

- All locks held by the transaction are released. This means that read operations performed by other transactions or threads of control can now see the modifications without resorting to uncommitted reads (see Reading Uncommitted Data for more information).

To commit a transaction, you simply call `Transaction.commit()`.

Remember that transaction commit causes only the BTree leaf nodes to be written to JE's log files. Any other modifications made to the the BTree as a result of the transaction's activities are not written to the log file. This means that over time JE's normal recovery time can greatly increase (remember that JE always runs normal recovery when it opens an environment).

For this reason, JE by default runs the checkpointer thread. This background thread runs a checkpoint on a periodic interval so as to ensure that the amount of data that needs to be recovered upon environment open is minimized. In addition, you can also run a checkpoint manually. For more information, see Checkpoints.

Note that once you have committed a transaction, the transaction handle that you used for the transaction is no longer valid. To perform database activities under the control of a new transaction, you must obtain a fresh transaction handle.

Prev |  | Next
Chapter 2. Enabling Transactions | Home | Non-Durable Transactions