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

Lock Server Alternatives

Lock Servers are generally stand-alone processes, but you can also link a link server with an application server process. That improves performance for the threads in that process. It is a fully functional lock server, so it will service requests from other processes and client machines.

The Objectivity/DB engineering team has considered several lock server implementations over the past few years. We already support distributed transaction management, e.g. using JCA to commit data into Objectivity/DB and some other database. There has been quite a lot of academic work on user customizable transaction modes that can interoperate safely. Clearly, you can't have two applications having different opinions of what "Exclusive Write Access" means. However, it would allow users to define their own semantics for nested, co-operating and other novel transaction modes.

I'll come back to the lock servers and their role in data replication in a future article. If you have any thoughts or requests regarding locking and transaction management, please let us know by commenting on this topic.