I believed most of you used Oracle before here, known its error
'ORA-08177: can't serialize access for this transaction'. In mysql,
this protection was gone, instead it bring in a big mistake when
isolating transactions in mysql/Innodb as illustrated below.

There are two clients (1 and 2), trying to update two rows (i,j) in one
table (t), initial setup as below

mysql> use test;
Database changed
mysql> create table t (i int,j int);
Query OK, 0 rows affected (0.05 sec)

mysql> insert into t values (1,1),(3,3);
Query OK, 2 rows affected (0.08 sec)
Records: 2 Duplicates: 0 Warnings: 0

Client 1:
=================

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t;
+------+------+
2 rows in set (0.00 sec)

Client 2:
====================

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t;
+------+------+
2 rows in set (0.01 sec)

mysql> update t set i=3 where j=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> update t set i=1 where j=3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from t;
+------+------+
2 rows in set (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.07 sec)

mysql> select * from t;
+------+------+
2 rows in set (0.00 sec)

Client 1: (physically no error in update, but it has logical error)
================================================== =================

mysql> select * from t;
+------+------+
2 rows in set (0.00 sec)

mysql> update t set i=2 where i=3;
Query OK, 1 row affected (0.00 sec) <-------------- physically no
error!!!
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from t;
+------+------+
2 rows in set (0.00 sec)


In conclusion, mysql didn't check the row version has been changed or
not when doing the update action! Which is a mysql/Innodb architecture
design defeat! In Oracle, you will got the error 'ORA-08177: can't
serialize access for this transaction' when client 2 is trying to
update the rows!