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 modes. In Oracle mode, the Read Committed and Serializable transaction isolation levels are supported. In MySQL mode, the Read Committed and Repeatable Read 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.