nested.so

berkeley db 4.6.21的源码。berkeley db是一个简单的数据库管理系统

m4_comment([$Id: nested.so,v 10.23 2003/01/24 18:01:58 bostic Exp $])

m4_ref_title(m4_tam Applications,
    Nested transactions,
    nested @transactions, transapp/cursor, transapp/admin)

m4_p([dnl
m4_db provides support for nested transactions.  Nested transactions
allow an application to decompose a large or long-running transaction
into smaller units that may be independently aborted.])

m4_p([dnl
Normally, when beginning a transaction, the application will pass a NULL
value for the parent argument to m4_ref(txn_begin).  If, however, the
parent argument is a m4_ref(DbTxn) handle, the newly created transaction
will be treated as a nested transaction within the parent.  Transactions
may nest arbitrarily deeply.  For the purposes of this discussion,
transactions created with a parent identifier will be called
m4_italic(child transactions).])

m4_p([dnl
Once a transaction becomes a parent, as long as any of its child
transactions are unresolved (that is, they have neither committed nor
aborted), the parent may not issue any m4_db calls except to begin more
child transactions, or to commit or abort.  For example, it may not
issue any access method or cursor calls.  After all of a parent's
children have committed or aborted, the parent may again request
operations on its own behalf.])

m4_p([dnl
The semantics of nested transactions are as follows.  When a child
transaction is begun, it inherits all the locks of its parent.  This
means that the child will never block waiting on a lock held by its
parent.  Further, locks held by two children of the same parent will
also conflict.  To make this concrete, consider the following set of
transactions and lock acquisitions.])

m4_p([dnl
Transaction T1 is the parent transaction.  It acquires a write lock on
item A and then begins two child transactions: C1 and C2.  C1 also wants
to acquire a write lock on A; this succeeds.  If C2 attempts to acquire
a write lock on A, it will block until C1 releases the lock, at which
point it will succeed.  Now, let's say that C1 acquires a write lock on
B.  If C2 now attempts to obtain a lock on B, it will block.  However,
let's now assume that C1 commits.  Its locks are anti-inherited, which
means they are given to T1, so T1 will now hold a lock on B.  At this
point, C2 would be unblocked and would then acquire a lock on B.])

m4_p([dnl
Child transactions are entirely subservient to their parent transaction.
They may abort, undoing their operations regardless of the eventual fate
of the parent.  However, even if a child transaction commits, if its
parent transaction is eventually aborted, the child's changes are undone
and the child's transaction is effectively aborted.  Any child
transactions that are not yet resolved when the parent commits or aborts
are resolved based on the parent's resolution -- committing if the
parent commits and aborting if the parent aborts.  Any child
transactions that are not yet resolved when the parent prepares are also
prepared.])

m4_page_footer