Database Transaction Management Paradigms

Almost all DBMSs (database management systems) provide some form of transaction management. The most common mechanism enforces a set of properties commonly known as ACID (Atomicity, Consistency, Isolation and Durability). A transaction can be regarded as a single logical operation that either succeeds or fails. If the transaction succeeds it may have altered the state of the database. If the transaction fails it should not have changed anything in the database. If the transaction succeeds and has changed the database then the alterations are persistent. They can only be removed by undoing the transaction, generally by using some kind of database operation (write, delete, update etc.) or "before look" log.

I've posted a series of pages detailing several issues related to transaction management, along with related  decisions made in the development of Objectivity/DB, our distributed data management solution - a market leader used in some of the most complex systems in use today. Here are the jump links:

1. DBMS Design Decisions
2. Lock Granularity
3. Locking Semantics
4. Novel Transaction Modes
5. Lock Server Alternatives