Transaction Management

GaussDB(DWS) supports the ACID properties of database transactions. It provides the READ COMMITTED and REPEATABLE READ isolation levels of transactions.

Concepts

Purposes

The purposes of database transactions are as follows:

Transaction Execution Process

After a transaction is committed in DBMS, DBMS needs to ensure that all operations in the transaction are successfully completed and the results are permanently stored in the database. If an operation in the transaction fails, all the operations in the transaction must be rolled back to the status before the transaction is executed. Transactions run independently and do not interfere with each other or affect database running.

Transaction Properties

A transaction has atomicity, consistency, isolation, and durability (ACID) properties.

Table 1 ACID usage

ACID

Purpose

Atomicity

Concurrency control and fault recovery

Consistency

SQL integrity constraints (primary key and foreign key constraints)

Isolation

Concurrency control

Durability

Fault recovery

Common concurrency control technologies include lock-based and timestamp-based concurrency control. GaussDB(DWS) uses the two-phase lock technology for DDL statements and uses multi-version concurrency control (MVCC) for DML statements. GaussDB(DWS) databases fault recovery is based on WAL logs. MVCC mainly uses redo logs to ensure transaction read/write consistency.

Isolation Levels

Isolation prevents data inconsistency during the execution of concurrent transactions. A transaction isolation level specifies how concurrent transactions process the same object.

In GaussDB(DWS), transaction isolation levels are controlled by the GUC parameter transaction_isolation or the SET TRANSACTION syntax. The following isolation levels are supported. The default isolation level is READ COMMITTED.

Transaction Control Syntax

Transaction Example

A customer buys a $100 item in a store using an e-payment account. At least two operations are involved: 1. $100 is deducted from the customer's account. 2. $100 is added to the store's account. In DBMS, the two operations must be both completed or not executed at all.

  1. Create sample data.
    Create an account balance table and insert data. (Assume the store's and the customer's accounts each have $500.)
    1
2
3
4
5
    CREATE TABLE customer_info (
	NAME VARCHAR(32) PRIMARY KEY,
	MONEY INTEGER
);
INSERT INTO customer_info (name, money) VALUES ('buyer', 500), ('shop', 500);
    The table data shows that the store and customer each have $500.
    1
2
3
4
5
6
    SELECT * FROM customer_info;
 name  | money
-------+-------
 buyer |   500
 shop  |   500
(2 rows)
  2. Simulate a successful transaction.

    Deduct $100 from the customer's account and add $100 to the store's account.

    1
2
3
4
5
6
7
8
9
    UPDATE customer_info SET money = money-100 WHERE name IN (SELECT name FROM customer_info WHERE name = 'buyer');
UPDATE customer_info SET money = money+100 WHERE name IN (SELECT name FROM customer_info WHERE name = 'shop');

SELECT * FROM customer_info;
 name  | money
-------+-------
 buyer |   400
 shop  |   600
(2 rows)
  3. Restore initial values.
    1
2
3
4
5
6
7
    UPDATE customer_info SET money=500;
select * from customer_info;
 name  | money
-------+-------
 shop  |   500
 buyer |   500
(2 rows)
  4. Simulate a transaction failure.

    $100 is deducted from the customer's account but fails to be added to the store's account.

    1. Deduct $100 from the customer's account.
      1
      UPDATE customer_info SET money = money-100 WHERE name IN (SELECT name FROM customer_info WHERE name = 'buyer');
    2. The store finds a payment problem and terminates subsequent operations. An error is reported when the amount of money is added to the store's account. The execution of the following statement is terminated. (Only the store thinks that there is a problem with payment.)
      1
      UPDATE customer_info SET money = money+100 WHERE name IN (SELECT name FROM customer_info WHERE name = 'shop');
    3. Query the account balances. The consumer has paid $100 but store does not receive it.
      1
2
3
4
5
6
      SELECT * FROM customer_info;
 name  | money
-------+-------
 buyer |   400
 shop  |   500
(2 rows)

Without ACID properties, the account balances will be incorrect once an error occurs during SQL statement execution..

Simulate the rollback of an abnormal database transaction.
  1. Restore initial values.
    1
    UPDATE customer_info SET money=500;
  2. Deduct $100 from the customer's account.
    1
2
    BEGIN TRANSACTION;
UPDATE customer_info SET money = money-100 WHERE name IN (SELECT name FROM customer_info WHERE name = 'buyer');
  3. An error is reported when the amount of money is added to the store's account. The execution of the following statement is terminated.
    1
    UPDATE customer_info SET money = money+100 WHERE name IN (SELECT name FROM customer_info WHERE name = 'shop');
  4. Roll back the transaction. All the completed database operations related to the transaction are canceled.
    1
2
3
4
    ERROR:  syntax error at or near "shop"
LINE 1: ...e IN (SELECT name FROM customer_info WHERE name = ''shop'');
END TRANSACTION;
ROLLBACK
  5. Query the account balances. The query result shows that the account balances remain unchanged. If an error occurs during transaction execution, the database is rolled back to the state before the transaction starts. The integrity of the database is not damaged.
    1
2
3
4
5
6
    SELECT * FROM customer_info;
 name  | money
-------+-------
 buyer |   500
 shop  |   500
(2 rows)

Two-Phase Transaction

GaussDB(DWS) uses the distributed shared nothing architecture. Table data is distributed on different nodes. One or more statements on the client may modify data on multiple nodes at the same time. In this case, a distributed transaction is generated. GaussDB(DWS) uses two-phase commit transactions to ensure data consistency and atomicity in distributed transactions. Two-phase commit divides transaction commit into two phases, usually for transactions that contain write operations. When data is written to different nodes, the atomicity requirement of the transaction must be met, that is, either all data is committed or all data is rolled back.

Two-phase commit is not supported in the following scenarios:

Parent topic: SQL Syntax Reference