Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "the characteristics of PHP and Mysql transactions and common distributed transaction solutions". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

ACID characteristics of transactions

Transactions should have four attributes: atomicity, consistency, isolation, and persistence

Atomicity (atomicity). A transaction is an indivisible unit of work, and all the operations included in the transaction are either done or not done.

Consistency (consistency). The transaction must change the database from one consistency state to another. Consistency is closely related to atomicity.

Isolation (isolation). The execution of one transaction cannot be interfered with by other transactions. That is, the operations and the data used within a transaction are isolated from other concurrent transactions, and the concurrent transactions can not interfere with each other.

Persistence (durability). Persistence, also known as permanence, means that once a transaction is committed, its changes to the data in the database should be permanent. Other operations or failures that follow should not affect it in any way.

Distributed transaction: the participants, resource managers and transaction managers of distributed transactions are located on unused nodes, and these different nodes cooperate with each other to complete a transaction with logical integrity.

Mysql supports XA DataSource since 5. 0. The version of Connector/J should use version 5.0, which is not supported by those below.

Common distributed transaction solutions are based on two-phase commit of XA protocol

XA protocol was first proposed by Tuxedo and handed over to X/Open as the interface standard between resource manager (database) and transaction manager. At present, Oracle, Informix, DB2 and Sybase and other major database manufacturers provide support for XA. XA protocol uses two-phase commit to manage distributed transactions. The XA interface provides a standard interface for communication between resource managers and transaction managers. The XA protocol consists of two sets of functions, starting with xa_ and starting with ax_.

The following functions enable the transaction manager to operate on the resource manager:

1) xa_open,xa_close: establish and close a connection to the resource manager.

2) xa_start,xa_end: start and end a local transaction.

3) xa_prepare,xa_commit,xa_rollback: pre-commit, commit, and roll back a local transaction.

4) xa_recover: rollback a transaction that has been pre-committed.

5) the function at the beginning of ax_ enables the resource manager to register dynamically with the transaction manager and to operate on XID (TRANSACTION IDS).

6) ax_reg,ax_unreg; allows a resource manager to register or unregister dynamically in a TMS (TRANSACTION MANAGER SERVER).

The principles of XA to implement distributed transactions are as follows:

MySQL XA is divided into two categories: internal XA and external XA; internal XA are used for transactions across multiple engines under the same instance, with the familiar Binlog as the coordinator; external XA is used for distributed transactions across multiple MySQL instances, which requires application layer intervention as the coordinator (suspended transactions in case of crash, global commit or rollback need to be decided by the application layer, and the implementation of the application layer is more demanding)

Binlog acts as the coordinator of the internal XA, and binlog is responsible for submitting the internal xid that appears in the binlog at the time of crash recover. (this is because binlog does not prepare, only commit, so the internal xid that appears in binlog must be able to guarantee that it has completed prepare in the underlying storage engines.)

External XA of MySQL database can be used in distributed database proxy layer to support distributed transactions of MySQL database, such as open source proxy tools: NetEase's DDB, Taobao's TDDL,B2B 's Cobar and so on.

Example

Public function testAction () {$goods_id=1; $goods_name = "Big Watermelon"; $num = 1; $rs_order = $this- > test- > createorder ($goods_id,$goods_name,$num); $rs_goods = $this- > test- > deduction ($goods_id,$num) If ($rs_order ['status'] = = "success" & & $rs_goods [' status'] = = "success") {$this- > test- > commitdb ($rs_order ['XA']); $this- > test- > commitdb1 ($rs_goods [' XA']);} else {$this- > test- > rollbackdb ($rs_order ['XA']); $this- > test- > rollbackdb1 ($rs_goods [' XA']) } print_r ($rs_order); echo ""; print_r ($rs_goods); die ("dddd");} public function createorder ($goods_id,$goods_name,$num) {$XA = uniqid (""); $this- > _ db- > query ("XA START'$XA'"); $_ rs = true; try {$data = array () $data ['order_id'] = "V" .date ("YmdHis"); $data [' goods_name'] = $goods_name; $data ['goods_num'] = $num; $this- > _ db- > insert ("temp_orders", $data); $rs = $this- > _ db- > lastInsertId (); if ($rs) {$_ rs = true } else {$_ rs = false;}} catch (Exception $e) {$_ rs = false;} $this- > _ db- > query ("XA END'$XA'"); if ($rs) {$this- > _ db- > query ("XA PREPARE'$XA'") Return array ("status" = > "success", "XA" = > $XA);} else {return array ("status" = > "nosuccess", "XA" = > $XA);}} public function deduction ($id) {$XA = uniqid (""); $this- > db1- > query ("XA START'$XA'"); $last_rs = true Try {$sql = "select * from temp_goods where id ='$id' and goods_num > 0"; $rs = $this- > db1- > fetchRow ($sql); if (! empty ($rs)) {$sql = "update temp_goods set goods_num = goods_num-1 where id ='$id'"; $rd = $this- > db1- > query ($sql) If ($rd) {$last_rs = true;} else {$last_rs = false;}} else {$last_rs = false } catch (Exception $e) {$last_rs = false;;} $this- > db1- > query ("XA END'$XA'"); if ($last_rs) {$this- > db1- > query ("XA PREPARE'$XA'"); return array ("status" = > "success", "XA" = > $XA) } else {return array ("status" = > "nosuccess", "XA" = > $XA);}} / / commit the transaction! Public function commitdb ($xa) {return $this- > _ db- > query ("XA COMMIT'$xa'");} / rollback transaction public function rollbackdb ($xa) {return $this- > _ db- > query ("XA ROLLBACK'$xa'");} / / commit transaction! Public function commitdb1 ($xa) {return $this- > db1- > query ("XA COMMIT'$xa'");} / / rollback transaction public function rollbackdb1 ($xa) {return $this- > db1- > query ("XA ROLLBACK'$xa'");}

Summary

Distributed transaction, in essence, is the unified control of multiple database transactions, which can be divided into non-control, partial control and complete control according to the intensity of control. No control means no introduction of distributed transactions, partial control is the two-phase commit of various variants, including the message transaction + final consistency and TCC mode mentioned above, while complete control is the full realization of two-phase commit. The advantage of partial control is that the concurrency and performance are good, but the disadvantage is that data consistency is weakened, while full control sacrifices performance to ensure consistency. Which way is used ultimately depends on the business scenario. As a technician, we must not forget that technology serves the business, and do not use technology for the sake of technology. Technology selection for different businesses is also a very important ability.

That's all for "the features of PHP and Mysql transactions and common distributed transaction solutions". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.