Implement repeatable read transaction isolation for RocksDB about mysql-5.6

[hermanlee]

Comment by yoshinorim
Thursday Feb 05, 2015 at 09:26 GMT

---

https://reviews.facebook.net/D32355

[hermanlee]

Comment by mdcallag
Thursday Feb 05, 2015 at 14:51 GMT

---

How was repeatable read implemented?

On Thu, Feb 5, 2015 at 9:26 AM, Yoshinori Matsunobu <
[email protected]> wrote:

Closed #6 MySQLOnRocksDB#6.

—
Reply to this email directly or view it on GitHub
MySQLOnRocksDB#6 (comment).

Mark Callaghan
[email protected]

[hermanlee]

Comment by yoshinorim
Thursday Feb 05, 2015 at 15:21 GMT

---

Needs more test cases (and likely implementation) to cover this -- https://github.com/MariaDB/webscalesql-5.6/wiki/Cursor-Isolation

[hermanlee]

Comment by mdcallag
Thursday Feb 05, 2015 at 15:39 GMT

---

Decisions to be made:

1. match PG or InnoDB semantics for RR. I think PG is easier to implement but will have more conflicts detected so db users see more errors
2. get snapshot on BEGIN or on first read after BEGIN when RR is used. InnoDB gets snapshot on first read after BEGIN

[hermanlee]

Comment by mdcallag
Thursday Feb 05, 2015 at 15:42 GMT

---

Basic test to distinguish between InnoDB and PG RR:

1. trx1: BEGIN
2. trx2: BEGIN
3. trx1: SELECT to establish snapshot (assuming it wasn't set on BEGIN)
4. trx2: SELECT to establish snapshot
5. trx1: UPDATE foo set x=2 where y=1
6. trx1: COMMIT
7. trx2: UPDATE foo set x=3 where y=1

I have not tested this but assume that PG gets an error from the write conflict and InnoDB does not because trx2 will see the version of the row after the COMMIT by trx1