0%

Install

Dependence

In order to generate Makefile, compile the code, and link the databases.

It’s necessary to install:

  • CMake

  • ODBC

  • Database to be tested(e.g. mysql)

  • The connector corresponding to the database (e.g. mysql-connector-odbc)

  • etc.

Usage

To generate Makefile (all commands are executed under ‘3TS/src/dbtest’):

1
cmake -S ./

To complie the code:

1
make

Example

For test cases, it specify in “do_test_list.txt”. Use “#” to exclude (comment) the test case.
We provide three levels of test cases, i.e., the basic cases (33 anomalies in the paper), the predicate cases, and the MDA cases (with multiple transactions and objects). For specific test cases to evaluate, we specify it in do_test_list.txt.

1
2
3
4
5
6
7
8
// to test all test cases
cp t/bk_do_test_list_all.txt do_test_list.txt

// to test only basic cases
cp t/bk_do_test_list_basic.txt do_test_list.txt

// to test only predicate cases
cp t/bk_do_test_list_predicate.txt do_test_list.txt

Edit “auto_test.sh” for database configurations (e.g., username, password). Edit “auto_test_all.sh” for databse (e.g., PostgreSQL, and MySQL) and isolation (e.g., SERIALIZABLE, REPEATABLE READ, READ COMMITTED, and READ UNCOMMITTED) configuration.

To run the test (under ‘3TS/src/dbtest’):

1
./auto_test_all.sh

Config

When generating the Makefile, you may get the following error message

1
2
3
4
5
6
Could not find a package configration file provided by "odbc" with any of
the following names:


odbcConfig.cmake
odbc-config.cmake

To solve this error:

1
2
3
4
find / -name "FindODBC.cmake"

//filepath is obtained by "find"
cp filepath/FindODBC.cmake 3TS/src/dbtest

Then update CMakeList.txt.

Write in:

1
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR})

Modify:

1
find_package(odbc REQUIRED) ---> find_package(ODBC REQUIRED)

Analyze an anomaly case run by PostgreSQL

Setup PostgreSQL

Please check out the general environment setup and PostgreSQL setup.

Check if it successfully connects to PostgreSQL server by isql,

1
isql pg -v

Once the connected information showed, we are able to run our code to test designed anomaly schedules.

The anomaly test cases are Write-read Skew and Write-read Skew Committed, the schedules are as follows:

Write-read Skew :

Write-read Skew Committed :

Under “src/dbtest/“ folder, add rat_dda_write_read_skew and rat_dda_write_read_skew_committed to “do_test_list.txt”.
Add the following to “auto_test_all.sh” for runing PostgreSQL with four isolation levels:

1
2
3
4
./auto_test.sh "pg" "read-uncommitted"
./auto_test.sh "pg" "read-committed"
./auto_test.sh "pg" "repeatable-read"
./auto_test.sh "pg" "serializable"

Run test by “./auto_test_all.sh”. The test result are in the following:

Isolation level Write-read Skew (SQL) Write-read Skew Committed (SQL)
Serializable Rollback (result) Rollback (result)
Repeatable Read Anomaly reported (result) Anomaly reported (result)
Read (Un)Committed Anomaly reported (result) Pass the test (result)

At serializbale level, both tested cases detected consecutive RW conflicts.
At Repeatable Read level, both generated two consecutive RW confilcts and allowed.
At Read (Un)Committed level, Write-read Skew test case generated two consecutive RW ($R_2W_1,R_1W_2$) conflicts while Write-read Skew Committed test case read the newest committed version and executed into non-anomaly schedule ($R_2W_1,W_2C_2R_1$).

License

GPLv3 @ Tencent