tiny-lsm/book/lab5/lab5.2-Tranc-ID

[giscus[bot]]

tiny-lsm/book/lab5/lab5.2-Tranc-ID

https://vanilla-beauty.github.io/tiny-lsm/book/lab5/lab5.2-Tranc-ID.html

[TTarkooo]

想请教一下作者，我看complete分支的代码中，读已提交和可重复读的commit实现逻辑不同，为什么是这样的呢？对于可重复读，get的时候会保留第一次读到的记录，以后都读这份记录。这样的话即使可重复读级别下允许旧事务比新事务更晚commit，由于第一次的时候保留了记录，也会一直读到相同的。所以是不是可以让可重复读的commit和读已提交那样不进行写冲突检测呢？

[Vanilla-Beauty]

这里冲突检测是避免脏写，和读没有关系吧

[1Leven2]

Read Committed 既然可以读到别的事务提交的结果，说明 Read Committed 的事务版本更新（tranc_Id 越大），因此在 Read Comitted 的隔离级别下，提交是不用进行写冲突检测的。而 Repeatable Read 在开启事务后，都认为自己是最旧的版本（tranc_id 最小），不能读到别的事务提交的结果，因此在 Repeatable Read 的隔离级别下，提交时，需要检测是否存在更新的版本（更大的 tranc_id）已经提交的结果

[HC10LY]

有个问题想请教一下作者，可重复读的commit只需要检测tranc_id就可以吗，就是如果有一个tranc_id小的事务T1，在事务T2开始的时候还没有提交，然后T1和T2修改同一个key的value，然后T1先提交，这个时候T2提交的时候只需要检查tranc_id的大小，不需要判断原来的value有没有被其他事务修改过吗

[Vanilla-Beauty]

这里t2本来就是在t1之后创建的，所以他可以不用管比自己序列号小的事务的提交，而只需要考虑比自己序列号打的事务的提交

[Vanilla-Beauty]

也就是说，t1只要先提交，t2根本不需要检查t1的任何修改，无论key是否相同

[Liang-bk]

在sst中查询key所在block块时（SST::find_block_idx(const std::string &key)）不需要指定tranc_id吗？
如果level0里的sst文件中同一个key恰好跨了两个或以上的block块，不指定tranc_id好像会出问题：比如find_block_idx(key1)定位到block3，但是block2的最后一个key1才是最新的，然后SST::get返回的迭代器只会在block3中找key1