This chapter walks you through a simple demonstration of how TiKV’s distributed transaction works.

Prerequisites

Before you start, ensure that you have set up a TiKV cluster and installed the tikv-client Python package according to TiKV in 5 Minutes.

TiKV Java client’s Transaction API has not been released yet, so the Python client is used in this example.

Test snapshot isolation

Transaction isolation is one of the foundations of database transaction processing. Isolation is one of the four key properties of a transaction (commonly referred as ACID).

TiKV implements Snapshot Isolation (SI) consistency, which means that:

  • all reads made in a transaction will see a consistent snapshot of the database (in practice TiKV Client reads the last committed values that exist when TiKV Client starts);
  • the transaction will successfully commit only if the updates that a transaction has made do not conflict with the concurrent updates made by other transactions since that snapshot.

The following example shows how to test TiKV’s snapshot isolation.

Save the following script to file test_snapshot_isolation.py.

  1. from tikv_client import TransactionClient
  3. client = TransactionClient.connect("127.0.0.1:2379")
  5. # clean
  6. txn1 = client.begin()
  7. txn1.delete(b"k1")
  8. txn1.delete(b"k2")
  9. txn1.commit()
  11. # put k1 & k2 without commit
  12. txn2 = client.begin()
  13. txn2.put(b"k1", b"Snapshot")
  14. txn2.put(b"k2", b"Isolation")
  16. # get k1 & k2 returns nothing
  17. # cannot read the data before transaction commit
  18. snapshot1 = client.snapshot(client.current_timestamp())
  19. print(snapshot1.batch_get([b"k1", b"k2"]))
  21. # commit txn2
  22. txn2.commit()
  24. # get k1 & k2 returns nothing
  25. # still cannot read the data after transaction commit
  26. # because snapshot1's timestamp < txn2's commit timestamp
  27. # snapshot1 can see a consistent snapshot of the database
  28. print(snapshot1.batch_get([b"k1", b"k2"]))
  30. # can read the data finally
  31. # because snapshot2's timestamp > txn2's commit timestamp
  32. snapshot2 = client.snapshot(client.current_timestamp())
  33. print(snapshot2.batch_get([b"k1", b"k2"]))

Run test script

  1. python3 test_snapshot_isolation.py
  3. []
  4. []
  5. [(b'k1', b'Snapshot'), (b'k2', b'Isolation')]

From the above example, you can find that snapshot1 cannot read the data before and after txn2 is commited. This indicates that snapshot1 can see a consistent snapshot of the database.

Try optimistic transaction model

TiKV supports distributed transactions using either pessimistic or optimistic transaction models.

TiKV uses the optimistic transaction model by default. With optimistic transactions, conflicting changes are detected as part of a transaction commit. This helps improve the performance when concurrent transactions infrequently modify the same rows, because the process of acquiring row locks can be skipped.

The following example shows how to test TiKV with optimistic transaction model.

Save the following script to file test_optimistic.py.

  1. from tikv_client import TransactionClient
  3. client = TransactionClient.connect("127.0.0.1:2379")
  5. # clean
  6. txn1 = client.begin(pessimistic=False)
  7. txn1.delete(b"k1")
  8. txn1.delete(b"k2")
  9. txn1.commit()
  11. # create txn2 and put k1 & k2
  12. txn2 = client.begin(pessimistic=False)
  13. txn2.put(b"k1", b"Optimistic")
  14. txn2.put(b"k2", b"Mode")
  16. # create txn3 and put k1
  17. txn3 = client.begin(pessimistic=False)
  18. txn3.put(b"k1", b"Optimistic")
  20. # txn2 commit successfully
  21. txn2.commit()
  23. # txn3 commit failed because of conflict
  24. # with optimistic transactions conflicting changes are detected when the transaction commits
  25. txn3.commit()

Run the test script

  1. python3 test_optimistic.py
  3. Exception: KeyError WriteConflict

From the above example, you can find that with optimistic transactions, conflicting changes are detected when the transaction commits.

Try pessimistic transaction model

In the optimistic transaction model, transactions might fail to be committed because of write–write conflict in heavy contention scenarios. In the case that concurrent transactions frequently modify the same rows (a conflict), pessimistic transactions might perform better than optimistic transactions.

The following example shows how to test TiKV with pessimistic transaction model.

Save the following script to file test_pessimistic.py.

  1. from tikv_client import TransactionClient
  3. client = TransactionClient.connect("127.0.0.1:2379")
  5. # clean
  6. txn1 = client.begin(pessimistic=True)
  7. txn1.delete(b"k1")
  8. txn1.delete(b"k2")
  9. txn1.commit()
  11. # create txn2
  12. txn2 = client.begin(pessimistic=True)
  14. # put k1 & k2
  15. txn2.put(b"k1", b"Pessimistic")
  16. txn2.put(b"k2", b"Mode")
  18. # create txn3
  19. txn3 = client.begin(pessimistic=True)
  21. # put k1
  22. # txn3 put data failed because of conflict
  23. # with pessimistic transactions conflicting changes are detected when writing data
  24. txn3.put(b"k1", b"Pessimistic")

Run the test script

  1. python3 test_pessimistic.py
  3. Exception: KeyError

From the above example, you can find that with pessimistic transactions, conflicting changes are detected at the moment of data writing.