Playful MySQL 2: Transactions and some of its potential problems

摘要: MySQL transactions are business sequence commends that execute as a whole unit. This blog gives a brief introduction to MySQL transaction, and demonstrates two typical transaction problems: lost update and deadlock.

A Brief Introduction to Transaction in MySQL

Transactions has 4 properties called "ACID". (Atomicity, Consistency, Isolation and Durability)

To write a transaction in MySQL:

SET AUTOCOMMIT = FALSE;

BEGIN;
# Or: START TRANSACTION;

/*PUT TRANSACTION HERE*/

COMMIT;
# OR ROLLBACK;

SET AUTOCOMMIT = TRUE;

If committed, then the results will be written into the disk by buffer pool, if rolled back, then the changes in buffer pools are cleaned and no matter what happened, those changes in buffer bool, disks and query compilers about the transaction shall all be traceable in database log.

Demo of Potential Transaction Problems using Windows cmd

The demonstration schema names "transac_demo". It has an account table whose structure is:

/* set up the database */
DROP TABLE IF EXISTS Account;
CREATE TABLE Account (Id int, AccountType char(10), Balance decimal(10,2), primary key(Id));
INSERT INTO Account values
(1, 'savings', 5000), (2, 'credit', 1000);

To use Windows command line to demonstrate transaction, open the directory of the "bin" file of the MySQL server, whose default path is "C:\Program Files\MySQL\MySQL Server 5.7\bin". Then type

mysql -u USERNAME -p -h HOSTNAME SCHEMA

Usually, for local database retrieval, USERNAME is root while HOSTNAME is localhost, SCHEMA in this case is transac_demo, if logged in successfully, it should look like the figure shown below.



By typing "quit", or simply close the window, to log out the client program.

Lost Update

Lost update could happen when different users are reading and writing (reader 1 reads before writer 2 writes and then reader 1 writes) to the same piece of data.
To see how this problem occurs, open two command line windows and log into the server for each of them, then perform jobs as seen below consequently:





Both of the "users" (simulated by 2 command lines) in this case are taking money out from a same account (say, in a case of a company account where 2 account managers are taking money). The result thus should be 4800. But after both have finished, the result is still 4900, in this case, one of the update got "lost" and this is called the lost update problem.

The solution to this is to use an "exclusive lock". Code in both sides are:

SET AUTOCOMMIT = FALSE;
BEGIN;
/*An exclusive lock is used, this is row level.*/
SELECT balance FROM Account WHERE id = 1 INTO @bal FOR UPDATE;
SET @newbal = @bal - 100;
UPDATE Account SET balance = @newbal WHERE id = 1;
COMMIT;
SET AUTOCOMMIT = TRUE;

As shown in the figure below.



User 2 (simulated as the green cmd) waits until user 1 (simulated as black cmd) finishes update, or time out (60 seconds). Otherwise it is keep locked as can be seen. Only when user 1 finishes update can user 2 then execute update. One successful transaction of user 1 and 2 can be shown as below:

Deadlock

Deadlock happens when user 1 is holding resource 1 and requesting for resource 2 while user 2 is holding resource 2 while requesting for resource 1. This might also happen in database. To see this, following the steps below.

In both command windows, type:

SET AUTOCOMMIT = FALSE;

Open cmd1, type:

SELECT balance FROM Account WHERE id = 1 FOR UPDATE;

Open cmd2, type:

SELECT balance FROM Account WHERE id = 2 FOR UPDATE;

Open cmd1 again, type:

SELECT balance FROM Account WHERE id = 2 FOR UPDATE;

Open cmd2 again, type:

SELECT balance FROM Account WHERE id = 1 FOR UPDATE;

Now the report of deadlock shall be observed, as shown in the figure below.



Finally, type

SET AUTOCOMMIT = TRUE;

to finish this demo and restore the database to proper status.

Note: You can use

SELECT @@autocommit;

to check your current status of automatic commition.