atomicity.so

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

m4_comment([$Id: atomicity.so,v 10.3 2002/05/17 15:48:41 bostic Exp $])

m4_ref_title(m4_tam Applications,
    Atomicity,, transapp/put, transapp/inc)

m4_p([dnl
The second reason listed for using transactions was m4_italic(atomicity).
Atomicity means that multiple operations can be grouped into a single
logical entity, that is, other threads of control accessing the database
will either see all of the changes or none of the changes.  Atomicity
is important for applications wanting to update two related databases
(for example, a primary database and secondary index)  in a single
logical action.  Or, for an application wanting to update multiple
records in one database in a single logical action.])

m4_p([dnl
Any number of operations on any number of databases can be included in
a single transaction to ensure the atomicity of the operations.  There
is, however, a trade-off between the number of operations included in
a single transaction and both throughput and the possibility of
deadlock.  The reason for this is because transactions acquire locks
throughout their lifetime and do not release the locks until commit or
abort time.  So, the more operations included in a transaction, the more
likely it is that a transaction will block other operations and that
deadlock will occur.  However, each transaction commit requires a
synchronous disk I/O, so grouping multiple operations into a transaction
can increase overall throughput.  (There is one exception to this: the
m4_ref(DB_TXN_WRITE_NOSYNC) and m4_ref(DB_TXN_NOSYNC) flags cause
transactions to exhibit the ACI (atomicity, consistency and isolation)
properties, but not D (durability); avoiding the write and/or
synchronous disk I/O on transaction commit greatly increases transaction
throughput for some applications.)])

m4_p([dnl
When applications do create complex transactions, they often avoid
having more than one complex transaction at a time because simple
operations like a single m4_ref(dbh_put) are unlikely to deadlock with
each other or the complex transaction; while multiple complex
transactions are likely to deadlock with each other because they will
both acquire many locks over their lifetime.  Alternatively, complex
transactions can be broken up into smaller sets of operations, and each
of those sets may be encapsulated in a nested transaction.  Because
nested transactions may be individually aborted and retried without
causing the entire transaction to be aborted, this allows complex
transactions to proceed even in the face of heavy contention, repeatedly
trying the suboperations until they succeed.])

m4_p([dnl
It is also helpful to order operations within a transaction; that is,
access the databases and items within the databases in the same order,
to the extent possible, in all transactions.  Accessing databases and
items in different orders greatly increases the likelihood of operations
being blocked and failing due to deadlocks.])

m4_page_footer