Questions about Daos consistency


段世博
 

     In the VOS document, the MVCC section mentions "The MVCC rules ensure that transactions execute as if they are serialized in their epoch order while complying with external consistency, as long as the system clock offsets are always within the expected maximum system clock offset (epsilon )."
    I want to know whether the external consistency here has the same meaning as spanner's external consistency? which is "In addition if one transaction completes before another transaction starts to commit, the system guarantees that clients can never see a state that includes the effect of the second transaction but not the first."


Li, Wei G
 

Yes. A DAOS client can only "see a state” via unversioned transactions (including I/O operations submitted without an explicit transaction) and explicitly-created snapshots. If an application hacks the snapshot epoch, however, effectively specifying an arbitrary version that may not have been snapshotted, then no transactional consistency is promised.

liwei

On Mar 16, 2021, at 10:01 PM, 段世博 <duanshibo.d@gmail.com> wrote:

In the VOS document, the MVCC section mentions "The MVCC rules ensure that transactions execute as if they are serialized in their epoch order while complying with external consistency, as long as the system clock offsets are always within the expected maximum system clock offset (epsilon )."
I want to know whether the external consistency here has the same meaning as spanner's external consistency? which is "In addition if one transaction completes before another transaction starts to commit, the system guarantees that clients can never see a state that includes the effect of the second transaction but not the first."


段世博
 

  I found that the concurrency control of DAOS is similar to CockroachDB, but the following situations may occur in CockroachDB according to jepsen analysis (https://jepsen.io/analyses/cockroachdb-beta-20160829). C1 and C2 are two unrelated data. T2 starts after T1 is committed. However, the data returned by T3 only sees the writing of T2 while can not see the writing of T1. Obviously, this violates external consistency.

T3: r(C1) (not found) 
T1: w(C1)
T1: commit
T2: w(C2)
T2: commit
T3: r(C2) (found)
T3: commit
 
  Can this happen in DAOS? If can't, How Daos avoids this situation?
  Thanks.


Li, Wei G
 

You are right. This can also happen with DAOS. I will correct that document.

Thanks,
liwei

On Mar 19, 2021, at 4:06 PM, 段世博 <duanshibo.d@gmail.com> wrote:

I found that the concurrency control of DAOS is similar to CockroachDB, but the following situations may occur in CockroachDB according to jepsen analysis (https://jepsen.io/analyses/cockroachdb-beta-20160829). C1 and C2 are two unrelated data. T2 starts after T1 is committed. However, the data returned by T3 only sees the writing of T2 while can not see the writing of T1. Obviously, this violates external consistency.

T3: r(C1) (not found)
T1: w(C1)
T1: commit
T2: w(C2)
T2: commit
T3: r(C2) (found)
T3: commit

Can this happen in DAOS? If can't, How Daos avoids this situation?
Thanks.


Olivier, Jeffrey V
 

I may be missing something here but assuming T3 is at a later timestamp to T1, the read of C1 would update the read timestamp in the negative entry for C1 (based on a hash of the key).   Before T1 creates C1, it would check this timestamp, find a conflict, and be forced to restart at a later timestamp.

 

-Jeff

 

From: daos@daos.groups.io <daos@daos.groups.io> on behalf of Li, Wei G <wei.g.li@...>
Date: Friday, March 19, 2021 at 3:03 AM
To: daos@daos.groups.io <daos@daos.groups.io>
Subject: Re: [daos] Questions about Daos consistency

You are right. This can also happen with DAOS. I will correct that document.

Thanks,
liwei

> On Mar 19, 2021, at 4:06 PM, 段世博 <duanshibo.d@...> wrote:
>
>   I found that the concurrency control of DAOS is similar to CockroachDB, but the following situations may occur in CockroachDB according to jepsen analysis (https://jepsen.io/analyses/cockroachdb-beta-20160829). C1 and C2 are two unrelated data. T2 starts after T1 is committed. However, the data returned by T3 only sees the writing of T2 while can not see the writing of T1. Obviously, this violates external consistency.
>
> T3: r(C1) (not found)
> T1: w(C1)
> T1: commit
> T2: w(C2)
> T2: commit
> T3: r(C2) (found)
> T3: commit
>  
>   Can this happen in DAOS? If can't, How Daos avoids this situation?
>   Thanks.
>






段世博
 

T3 starts before T1, so T3 can obtain a timestamp less than T1. T1 has not yet started when T3 is read, so there will be no uncertain reading
When T1 writes C1, it does not check the read timestamp smaller than itself, so T3 cannot see the write of T1.