m4_comment([$Id: twopl.so,v 10.11 2001/05/22 19:39:32 bostic Exp $])

m4_ref_title(Locking Subsystem,
    Locking with transactions: two-phase locking,
    two-phase @locking, lock/notxn, lock/cam_conv)

m4_p([dnl
m4_db uses a locking protocol called m4_italic(two-phase locking (2PL)).  This
is the traditional protocol used in conjunction with lock-based transaction
systems.])

m4_p([dnl
In a two-phase locking system, transactions are divided into two
distinct phases.  During the first phase, the transaction only acquires
locks; during the second phase, the transaction only releases locks.
More formally, once a transaction releases a lock, it may not acquire
any additional locks.  Practically, this translates into a system in
which locks are acquired as they are needed throughout a transaction
and retained until the transaction ends, either by committing or
aborting.  In m4_db, locks are released during m4_ref(txn_abort) or
m4_ref(txn_commit).  The only exception to this protocol occurs when we
use lock-coupling to traverse a data structure.  If the locks are held
only for traversal purposes, it is safe to release locks before
transactions commit or abort.])

m4_p([dnl
For applications, the implications of 2PL are that long-running
transactions will hold locks for a long time.  When designing
applications, lock contention should be considered.  In order to reduce
the probability of deadlock and achieve the best level of concurrency
possible, the following guidelines are helpful.])

m4_nlistbegin
m4_nlist([dnl
When accessing multiple databases, design all transactions so that they
access the files in the same order.])
m4_nlist([dnl
If possible, access your most hotly contested resources last (so that
their locks are held for the shortest time possible).])
m4_nlist([dnl
If possible, use nested transactions to protect the parts of your
transaction most likely to deadlock.])
m4_nlistend

m4_page_footer