BDB XML supports the following levels of isolation:

By default, BDB XML transactions and transactional cursors offer serializable isolation. You can optionally reduce your isolation level by configuring BDB XML to use uncommitted read isolation. See Reading Uncommitted Data for more information. You can also configure BDB XML to use committed read isolation. See Committed Reads for more information.

Finally, in addition to BDB XML's normal degrees of isolation, you can also use snapshot isolation. This allows you to avoid the read locks that serializable isolation requires. See Using Snapshot Isolation for details.

Berkeley DB allows you to configure your application to read data that has been modified but not yet committed by another transaction; that is, dirty data. When you do this, you may see a performance benefit by allowing your application to not have to block waiting for write locks. On the other hand, the data that your application is reading may change before the transaction has completed.

That said, configuring BDB XML to read uncommitted data can result in internal inconsistencies which lead to random errors. For best results, you should avoid configuring your BDB XML transactions to read uncommitted data.

Committed Reads control the behavior of a Berkeley DB mechanism called a cursor. Cursors are not something you would normally be using directly with your BDB XML application, unless you are using Berkeley DB databases alongside of your BDB XML containers. For that reason, this section is potentially not of great interest to you. Still, we present it here for the sake of completeness.

For a thorough description of cursors, see the Getting Started with Berkeley DB guide.

You can configure your transaction so that the data being read by a transactional cursor is consistent so long as it is being addressed by the cursor. However, once the cursor is done reading the record (that is, reading records from the page that it currently has locked), the cursor releases its lock on that record or page. This means that the data the cursor has read and released may change before the cursor's transaction has completed.

For example, suppose you have two transactions, Ta and Tb. Suppose further that Ta has a cursor that reads record R, but does not modify it. Normally, Tb would then be unable to write record R because Ta would be holding a read lock on it. But when you configure your transaction for committed reads, Tb can modify record R before Ta completes, so long as the reading cursor is no longer addressing the record or page.

When you configure your application for this level of isolation, you may see better performance throughput because there are fewer read locks being held by your transactions. Read committed isolation is most useful when you have a cursor that is reading and/or writing records in a single direction, and that does not ever have to go back to re-read those same records. In this case, you can allow BDB XML to release read locks as it goes, rather than hold them for the life of the transaction.

To configure your application to use committed reads, do one of the following:

For example, the following creates a transaction that allows committed reads:

#include "DbXml.hpp"
...

using namespace DbXml;
int main(void)
{
    u_int32_t env_flags = DB_CREATE     |  // If the environment does not
                                           // exist, create it.
                          DB_INIT_LOCK  |  // Initialize locking
                          DB_INIT_LOG   |  // Initialize logging
                          DB_INIT_MPOOL |  // Initialize the cache
                          DB_THREAD     |  // Free-thread the env handle
                          DB_INIT_TXN;     // Initialize transactions

    DB_ENV *myEnv = NULL;
    XmlManager *myManager = NULL;
    char *envHome = "/export1/testEnv";
    int dberr;

    dberr = db_env_create(&myEnv, 0);
    if (dberr) {
        std::cout << "Unable to create environment: " <<
            db_strerror(dberr) << std::endl;
        if (myEnv)
            myEnv->close(myEnv, 0);
        return (EXIT_FAILURE);
    }

    myEnv->open(myEnv, envHome, env_flags, 0);
    myManager = new XmlManager(myEnv, 0);

    try {
        // Notice that we do not have to specify any options
        // to allow committed reads (this is as opposed 
        // to uncommitted reads where we DO have to specify  
        // options).

        XmlContainerConfig cconfig;
        cconfig.setAllowCreate(true);    // If the container does not 
                                         // exist, create it. 
        cconfig.setTransactional(true); // Enable transactions.

        std::string containerName = "myContainer.dbxml";
        XmlContainer myContainer =
            myManager->openContainer(containerName, cconfig);

    } catch(XmlException &e) {
        std::cerr << "Error opening container: " << std::endl;
        std::cerr << e.what() << std::endl;
        return (EXIT_FAILURE);
    } catch(std::exception &e) {
        std::cerr << "Error opening container: " << std::endl;
        std::cerr << e.what() << std::endl;
        return (EXIT_FAILURE);
    }

    // File to open
    std::string file1 = "doc1.xml";

    // Transaction handle
    // Open the transaction and enable committed reads.  All
    // queries performed with this transaction handle will 
    // use read committed isolation.
    XmlTransaction txn = myManager.createTransaction(DB_READ_COMMITTED);

    // From here, you perform your container reads and writes as normal,
    // committing and aborting the transactions as is necessary,  as well
    // as testing for deadlock exceptions as normal (omitted for brevity).

    ...

By default BDB XML uses serializable isolation. An important side effect of this isolation level is that read operations obtain read locks on database pages, and then hold those locks until the read operation is completed.

You can avoid this by using snapshot isolation. Snapshot isolation uses multiversion concurrency control to guarantee repeatable reads. What this means is that every time a writer would take a read lock on a page, instead a copy of the page is made and the writer operates on that page copy. This frees other writers from blocking due to a read lock held on the page.

#include "DbXml.hpp"
...

using namespace DbXml;
int main(void)
{
    u_int32_t env_flags = DB_CREATE     |  // If the environment does not
                                           // exist, create it.
                          DB_INIT_LOCK  |  // Initialize locking
                          DB_INIT_LOG   |  // Initialize logging
                          DB_INIT_MPOOL |  // Initialize the cache
                          DB_INIT_TXN;     // Initialize transactions
                          
    DB_ENV *myEnv = NULL;
    XmlManager *myManager = NULL;
    char *envHome = "/export1/testEnv";
    int dberr;

    dberr = db_env_create(&myEnv, 0);
    if (dberr) {
        std::cout << "Unable to create environment: " <<
            db_strerror(dberr) << std::endl;
        if (myEnv)
            myEnv->close(myEnv, 0);
        return (EXIT_FAILURE);
    }
    // Support snapshot isolation
    myEnv->set_flags(myEnv, DB_MULTIVERSION, 1);
    myEnv->open(myEnv, envHome, env_flags, 0);
    myManager = new XmlManager(myEnv, 0);

    try {
        // Note that no special options are required here for snapshot
        // isolation. This is because it is already enabled at the 
        // environment level.
        XmlContainerConfig cconfig;
        cconfig.setAllowCreate(true);   // If the container does not
                                        // exits, create it.
        cconfig.setTransactional(true); // Enable transactions

        std::string containerName = "myContainer.dbxml";
        XmlContainer myContainer =
            myManager->openContainer(containerName, cconfig);

    ...

    // Transaction handle
    XmlTransaction txn = myManager.createTransaction(DB_TXN_SNAPSHOT);

    // Remainder of program omitted for brevity.
    
    ...