In the commit path, previously mvstore returned last-write-version (LWV) to the client, and the client then checks whether LWV matches the local last known version. If so, changelog-based cache invalidation is skipped.
This is not correct with PLCC, since LWV is now a snapshot read. Concurrent commits started after FDB transaction read version will not be observed, and will not conflict on FDB commit.
In the Txn1 + Txn2a case, Txn1 will see LWV == Txn2 commit version and return that to the client. This is correct. But in the Txn1 + Txn2b case, Txn1 will see LWV == Txn1 mvSQLite RV, and the client will think nothing has happened during Txn1's execution. This is incorrect.
To fix this, the client needs to check whether the changelog is empty instead.
In the commit path, previously mvstore returned
last-write-version(LWV) to the client, and the client then checks whether LWV matches the local last known version. If so, changelog-based cache invalidation is skipped.This is not correct with PLCC, since LWV is now a snapshot read. Concurrent commits started after FDB transaction read version will not be observed, and will not conflict on FDB commit.
Consider the following order:
In the Txn1 + Txn2a case, Txn1 will see
LWV == Txn2 commit versionand return that to the client. This is correct. But in the Txn1 + Txn2b case, Txn1 will seeLWV == Txn1 mvSQLite RV, and the client will think nothing has happened during Txn1's execution. This is incorrect.To fix this, the client needs to check whether the changelog is empty instead.