As we know, a resolver keeps lastCommit including the kv ranges commited. My question is, how are these ranges merged?
For example,
transaction A commits (‘a’, v1),(‘c’,v1). so the resolver’s lastCommit would seem like [‘a’,‘a’]->v1, [‘c’,‘c’]->v1.
Now here comes transaction B, who commits (‘b’, v2)
So will the resolver merge these continuous ranges as [‘a’, ‘c’]->v1(or v2)? Or because (‘b’, v2) has a different commit version, so there will be a third range [‘b’, ‘b’]->v2 ?
On the opposite, assume the resolver has now the lastCommit [‘a’, ‘c’]->v1，and then a transaction commits (‘b’, v2)，will [‘a’,‘c’]->v1 be splited to be [‘a’,‘a’]->v1 [‘b’,‘b’]->v2 [‘c’,‘c’]->v1 as 3 ranges?
I assume in your example, (‘a’, v1) means a single key ‘a’ is modified. FDB will convert it to a key range that contains a single key: ["a", "a\x00") and the resolver keeps a history of key range to version mapping. Thus, transaction A’s history is like: ["a", "a\x00"), ["c", "c\x00) -> v1.
Similarly, B’s history is like: ["b", "b\x00) -> v2.
As you can see, these 3 ranges are non-overlapping.
Appreciated! Understood. So if ["a", "c\x00"), -> v1 already exists and now ‘b’ is modified with version v2 then the history will be split as ["a", "a\x00")->v1, ["b", "c\x00) -> v2, ["c", "c\x00) -> v1 ,right ? @jzhou