PHP declarative transaction processing

PHP declarative transaction processing 1. database transactions

Transaction is the basic unit of concurrency control. A transaction is a sequence of operations. these operations are either executed or not executed. it is an inseparable unit of work. For example, for bank transfers: if you deduct money from one account and add money to another account, either or both of these operations will be executed. Therefore, we should regard them as a transaction. A transaction is the unit in which the database maintains data consistency. data consistency can be maintained at the end of each transaction. Transactions have the following four basic features: ● Atomic (atomicity): operations contained in a transaction are considered as a logical unit. operations in this logical unit either succeed or fail. ● Consistency (Consistency): only valid data can be written to the database. Otherwise, the transaction should roll back to the original state. ● Isolation: transactions allow multiple users to concurrently access the same data without compromising the correctness and integrity of the data. At the same time, modifications to parallel transactions must be independent from those of other parallel transactions. ● Durability: After the transaction ends, the transaction processing result must be solidified.

2. database transaction management methods: 2.1 Transactional

In the code, transaction management methods such as beginTransaction (), commit (), and rollback () are explicitly called. Transaction Management requires programmers to explicitly call the methods related to transaction management in specific business code, and determine whether to commit or roll back based on various conditions explicitly. This method can also be used in a simple business system. for a complicated business system, incorrect submission or rollback may be caused by the absence of certain conditions, especially for systems with extremely frequent changes in business requirements, incorrect submission and rollback may occur because the judgment conditions are not modified in a timely manner based on business adjustments. Because transactional transactions need to be coupled with the business logic code, and it is difficult to judge or update rollback conditions in a timely manner, or even cause unexpected transaction nesting, therefore, it is not recommended to manage transactions in a transactional manner.

2.2 Declarative transactions

The declarative transaction management mechanism of the TP system is built on the behavior extension mechanism of the TP framework at the underlying layer. The essence is to start the transaction before the controller's target method is executed, and commit or roll back the transaction according to the actual situation after the controller's target method is executed.

The biggest advantage of declarative transactions is that you do not need to mix the transaction management code with the specific business logic code. you only need to declare the method to enable transaction management in the module configuration, transactions can be applied to the business logic.

3. TP project declarative transaction processing mechanism implementation 1) add two constants in the system constant configuration:

// Enable the database transaction define ('Db _ TRANS_ENABLE ', true); // The global identifier of the database transaction define ('Db _ TRANS_VAR', 'tx _ comment ');

2) load the add, addAll, delete, execute, and save methods in the Model class of the TP framework in BaseModel.

For details, see the relevant code.

3) in the run method of MyActionBeginBehavior, determine whether to enable database transactions based on the system Global transaction switch and module configuration.

// Enable database transactions
 
  
$ Db_trans_enable = C ('Db _ TRANS_ENABLE '); if (defined ('Db _ TRANS_ENABLE') & DB_TRANS_ENABLE & is_array ($ db_trans_enable) & in_array (strtolower (CONTROLLER_NAME. '. '. ACTION_NAME), $ db_trans_enable) {env (DB_TRANS_VAR, true); M ()-> startTrans ();}
 

4) in the run method of MyActionEndBehavior, determine whether to submit the transaction based on the value of the system Global transaction switch, module configuration, and environment variable DB_TRANS_VAR.

// Process database transactions by fanwall
 
  
$ Db_trans_enable = C ('Db _ TRANS_ENABLE '); if (defined ('Db _ TRANS_ENABLE') & DB_TRANS_ENABLE & is_array ($ db_trans_enable) & in_array (strtolower (CONTROLLER_NAME. '. '. ACTION_NAME), $ db_trans_enable) {$ tx_commit = env (DB_TRANS_VAR); if ($ tx_commit = false) {// roll back M ()-> rollback ();} else {// submit transaction M ()-> commit ();}}
 

5) force Rollback

If you set the value of the environment variable DB_TRANS_VAR to false in the code to be forcibly rolled back, the system will roll back after the target method ends.

4. existing problems 4.1 Database read/write splitting

After the database read/write splitting, a single request based on the TP framework will create at least two database connections, therefore, the current declarative transaction implementation mechanism needs to manage transactions based on read connections and write connections respectively.

4.2 transaction granularity

Compared with transactional transactions, declarative transactions can only be immersed in the method level of the controller, and cannot be immersed in the code block level as transactional transactions do, it is impossible to manage non-controller transactions. To be extended.

4.3 Impact of transactions on data

Phantom read: Transaction 1 reads records current affairs 2 adds records and commits, transaction 1 reads the new records of Transaction 2 again, and unrepeatable read cannot be repeated: when transaction 1 reads the record, transaction 2 updates the record and submits the record. when Transaction 1 reads the record again, the modified record of the transaction is displayed. dirty read: Transaction 1 updates the record, but not committed. Transaction 2 reads the updated row and then rolls back transaction T1. Currently, T2 reading is invalid. Phantom read, non-repeated read, dirty read, and other issues can be solved through the transaction isolation level of the database, to be optimized.

It should be noted that if the data is cached at the data model layer, the system may cause "dirty data" problems after the transaction is started, therefore, reading and writing of some important data fields cannot rely on cached data.

4.4 Distributed Transactions

Distributed Transactions may occur after Database/table sharding or the system adopts the microservice architecture. To be studied.