A database transaction is a series of database operations that are treated as a unit. The database is transformed from one consistent state to another after a transaction is executed.
Database transactions provide ways to:
Recover a sequence of failed database operations to the normal state and maintain database consistency even if the database is in the abnormal state.
Isolate concurrent access to a database and prevent concurrent operations from causing inconsistency in the database.
A database transaction is characterized by the following attributes: atomicity, consistency, isolation, and durability (ACID).
Atomicity
OceanBase Database is a distributed system. The tables or partitions on which a distributed transaction operates may reside on different servers. In this case, you can use the two-phase commit protocol to ensure the atomicity of transactions. In this way, all the transactions on multiple servers can be successfully committed or rolled back.
Consistency
A transaction must ensure that a database is transformed from one consistent state to another. Consistency and atomicity are closely related.
Isolation
OceanBase Database supports the Oracle- and MySQL-compatible modes. In Oracle-compatible mode, the Read Committed and Serializable transaction isolation levels are supported. In MySQL-compatible mode, the Read Committed, Repeatable Read, Read Uncommitted, and Serializable transaction isolation levels are supported.
Durability
On a single server, OceanBase Database uses REDO logs to record data changes, and the write-ahead logging (WAL) mechanism to ensure that data can be recovered after a downtime restart. This ensures that the data of a transaction will not be lost if the transaction is successfully committed. In a cluster, OceanBase Database uses the Paxos protocol to synchronize data to multiple replicas. In this way, the transaction data will not be lost if the majority of replicas are alive.