The information about transactions is organized in the following manner:

• Transactions Overview
• Using Transactions
• Using Lexical Transactions
• Using Dynamic Transactions
• Locking
• Organizing Transaction Code
• Rolling Back to Persistent State
• Threads and Thread Locking

Transactions in a database system serve two general purposes:

• They support fault tolerance.
• They support concurrent database access.

• Either all a transaction's changes to persistent memory are made successfully, or none are made at all. If a failure occurs in the middle of a transaction, none of its database updates are made.
• A transaction is not considered to have completed successfully until all its changes are recorded safely on stable storage. Once a transaction commits, failures such as server crashes or network failures cannot erase the transaction's changes.

Concurrency Control

• A transaction's changes to persistent data are private and invisible to other processes until the entire transaction completes successfully.
• Other processes' changes to persistent data are invisible to a transaction.

Transaction Commit and Abort

• Explicit aborts, which result from calls to transaction member functions. See Rolling Back to Persistent State.
• Aborts due to deadlock conditions. See Threads and Thread Locking.
• Aborts due to nonlocal transfer of control out of the scope of a lexical transaction. (See Using Transactions.) This can happen when an exception is signaled within a lexical transaction and handled outside it, or not handled at all.
• Aborts due to system failure.

Using Transactions

This applies to statements that access data in a database, but not to all statements that operate on a database. Statements that create, open, or close a database can be either inside or outside a transaction, although, generally, it is advisable not to open or close a database within a transaction.

Lexical and Dynamic Transactions

• Lexical transactions require that the transaction be contained in a lexical context. You mark off lexical transactions with the ObjectStore transaction macros. See Using Lexical Transactions.
• Dynamic transactions provide dynamically defined boundaries. You mark off dynamic transactions with members of the class os_transaction. See Using Dynamic Transactions.

Choosing Transaction Boundaries

• If a transaction includes too much, it can negatively affect the performance of other concurrent applications.
• If a transaction includes too little, other concurrent applications can interfere with the application containing the transaction, causing the application to produce incorrect results. Additionally, a greater number of transactions can increase overhead.

Multiversion Concurrency Control (MVCC)

Using Lexical Transactions

      OS_BEGIN_TXN( identifier,exception**,transaction-type)

      OS_END_TXN( identifier)

These and other ObjectStore macros are described in Chapter 4, System-Supplied Macros, in the ObjectStore C++ API Reference.

identifier is a transaction tag. The only requirement on the tag is that different transactions in the same function must use different tags. (The tags are used to construct statement labels, and so have the same scope as labels in C++.)

exception** specifies a location in which ObjectStore will store an exception* if the transaction is aborted because of the raising of an exception. Raising an exception will cause a lexical transaction to abort if the exception is handled outside the transaction's dynamic scope, or if there is no handler for the exception. The stored exception* indicates the exception that caused the abort. ObjectStore stores 0 in this location at the beginning of each transaction.

Transaction type enumerators

• os_transaction::update specifies a transaction in which updates to persistent memory are allowed.
• os_transaction::read_only specifies a transaction in which any attempt to update persistent memory signals the exception err_write_permission_denied.
• os_transaction::abort_only specifies a transaction in which writes to persistent memory are allowed, but the transaction cannot be committed.

Example: a lexical transaction

      #include <iostream.h>
      #include <ostore/ostore.hh>
      main(int, char **argv) {
            os_database *db1 = os_database::open( argv[1] ) ;
            OS_BEGIN_TXN(my_tx_1,0,os_transaction::update)
                  int countp* = (int*)( db1->find_root("count")->get_value() ) ;
                  cout << "Hello, world\n" ;
                  cout << ++*countp << "\n" ;
            OS_END_TXN(my_tx_1)
            db1->close() ;
      }

      static os_transaction *begin(
            os_int32 transaction_type = os_transaction::update      

      ) ;
      static void commit() ;
      static void commpwd
it( os_transaction* ) ;

Transaction type enumerators

• os_transaction::update specifies a transaction in which updates to persistent memory are allowed.
• os_transaction::read_only specifies a transaction in which any attempt to update persistent memory signals the exception err_write_permission_denied.
• os_transaction::abort_only specifies a transaction in which writes to persistent memory are allowed, but the transaction cannot be committed. An attempt to commit the transaction signals the exception err_commit_abort_only.

The first overloading of commit() commits the current transaction. In the case of nesting, it commits the most nested transaction. The second overloading of commit() commits the specified transaction.

Unlike lexical transactions, if a dynamic transaction is aborted due to deadlock, it is not automatically retried. See Threads and Thread Locking.

Locking

Waiting for Locks

Database- Compared to Segment-Level Locks

Read Locks and Write Locks

Lock Timeouts

Reducing Wait Time

Lock Probes

Explicit Lock Acquisition

Organizing Transaction Code

Guidelines for organizing code within a transaction

• You do not want other processes to see intermediate results of this code's execution.
• You want the state of the database to be frozen, from the point of view of the code being executed, for the duration of its execution. That is, no changes to the database made by other concurrent processes should be visible for the duration of the code's execution.

Hiding Intermediate Results

Suppose each of two processes is replacing two different children of a given part. Suppose further that each process must make some constraint check on the assembly after the replacement has been performed. Perhaps the total cost of the assembly must be checked against some allowable maximum cost.

In replacing a subpart, the first process removes a child part from the set of the assembly's children, and then inserts a different part into this set. But between the remove and insert, the assembly is in an intermediate state that should not be visible to the other process. Suppose, for example, the second process does its part replacement while the assembly is in this intermediate state, and then performs a cost check. The cost will be incorrect (too low), since a subpart is missing from the assembly. If the second process's new part raises the actual cost above the maximum, this will go undetected.

To prevent exposure of such intermediate states, the process should put the remove and the insert into the same transaction. This way, as far as other processes are concerned, the replacement happens all at once. In general, whatever happens within a single transaction looks to other processes as if it happens instantaneously, since the intermediate states are not visible to them.

Preventing Other Processes' Changes

Consider, for example, a routine that involves a recursive descent of a given assembly. Suppose that another process removes a subpart from the assembly, but it does not matter whether the descent is performed before or after the removal. Nevertheless, for this process to produce correct results, the assembly's descendents must not change during the descent itself. For if a subpart is removed after being visited, and then, before this removed subpart's children are visited, new children are added to it, these new children might be incorrectly visited as part of the original assembly's descendents. So all the code that performs the descent should be within the same transaction.

Rolling Back to Persistent State

Aborting the Current Transaction

      static void abort() ;

Persistent data is rolled back to its state as of the beginning of the transaction. In addition, if the aborted transaction is not nested within another transaction, all locks are released, and other processes can access the pages that the aborted transaction accessed.

Aborting the Top-Level Transaction

      static void abort_top_level() ;

      static void abort(os_transaction*) ;

      static os_transaction *get_current() ;

      os_transaction *get_parent() const ;

      os_transaction* child_tx = os_transaction::get_current() ;
      if (child_tx) {
            parent_tx = child_tx->get_parent() ;
            if (parent_tx)
                  os_transaction::abort(parent_tx) ;
      }

      main() {
            os_database *db5 = os_database::open("/user1/db5");
            OS_BEGIN_TXN(tx1,0,os_transaction::update)
                  os_typespec *part_type =  ...;
                  part *a_wheel =  ...;
                  part *a_rim =  ...;
                  a_wheel->children -= a_rim;
                  /* in this intermediate state, the wheel has no rim */
                  /* but this state is not visible to other processes */
                  a_wheel->children |= new(db5, part_type) part(...);
                  if (!check_cost(a_wheel)) {
                        cout << "change aborted: cost check failed\n";
                        /* undo the part replacement* /
                        os_transaction::abort(); 
                  } /* end if */
            OS_END_TXN(tx1)
            db5->close();
      }

Threads and Thread Locking

The thread-locking facility works by either serializing the transactions of different threads or serializing access by different threads to the ObjectStore run time. No two threads are ever in the ObjectStore run time at the same time.

Thread Safety

ObjectStore Release 5.1 provides a thread-safe version of the ObjectStore API. It does this by protecting the body of each API call with a mutex lock that only one thread can acquire at a time.

When You Need Thread Locking

• The thread dereferences a pointer to persistent memory.
• The thread calls an ObjectStore API function or macro.

Disabling and Enabling Thread Locking

      static void set_thread_locking(os_boolean) ;

      static os_boolean get_thread_locking() ;

Local and Global Transactions

The two kinds of transactions have the following characteristics:

• Local transaction: a thread enters a local transaction by calling os_transaction::begin() or OS_BEGIN_TXN(). When one thread enters a local transaction, this has no effect on whether other threads are within a transaction.
• Global transaction: a thread enters a global transaction when it calls os_transaction::begin() or when another thread of the same process calls os_transaction::begin(). When one thread enters a global transaction by calling os_transaction::begin(), all other threads automatically enter the same transaction.

Global transactions allow for a somewhat higher degree of concurrency. After one thread enters the ObjectStore run time, if another thread attempts to enter the ObjectStore run time, it is blocked until control in the first thread exits from the run time. Although two threads cannot be in the ObjectStore run time at the same time, there can be some interleaving of operations of different threads within a transaction. See Chapter 3, Threads, in the ObjectStore Advanced C++ API User Guide for more information on using threads with ObjectStore.

Costs and Benefits of Global Transactions

• Global transactions allow for a higher degree of concurrency.
• With local transactions, if one thread attempts to access persistent memory from outside a transaction while another thread is performing relocation, data corruption can result. No exception is signaled. With global transactions (as in the absence of threads), there is no such possibility. Any attempt to access persistent memory from outside a transaction results in err_no_trans.

• Global transactions have extra overhead, compared to local transactions, in the form of extra memory management, particularly if there is a lot of cache replacement.
• With global transactions, you must synchronize the threads so that no thread attempts to access persistent data while another thread is committing or aborting.

      enum os_transaction_scope {
            os_transaction::local = 1,os_transaction::global
      };
      static os_transaction::begin(
            os_int32 type = os_transaction::update,
            os_int32 scope = os_transaction::local
      );

The exception err_deadlock might be signaled asynchronously in any thread using persistent data; the application must be prepared to handle it. Once err_deadlock is handled in the first thread, any other threads that attempt to use the transaction will also get err_deadlock; in particular, any threads that were waiting for the global lock will wake up and immediately get err_deadlock.

Nesting and Global Transactions

Additional information about nested transactions is in Chapter 2, Advanced Transactions, of the ObjectStore Advanced C++ API User Guide. For further discussion of threads, see Chapter 3, Threads, of that publication.

Updated: 03/31/98 16:58:31