Let me focus on the properties you're bringing up, that's interesting. > two requirements needs to meet : a) > no operation would change the entries set added before time T. b) > distinguish entries added before fencing at time T and entries added after > that.
In this definition, T is the time that fencing completes, right? > for session fencing, fencing by incrementing session id meet a). And > session id is used to distinguish entries added between different sessions, > which meet b). Does it mean that we add another field to entries to say what the session id is? -Flavio On Jan 23, 2013, at 6:36 AM, Sijie Guo <[email protected]> wrote: > I had pointed out in previous email, that two requirements needs to meet : a) > no operation would change the entries set added before time T. b) > distinguish entries added before fencing at time T and entries added after > that. > > for closed, it obviously meet a) and application is forced to create a new > ledger to write. so different ledger ids are used here to meet b). > > for session fencing, fencing by incrementing session id meet a). And > session id is used to distinguish entries added between different sessions, > which meet b). > > go back to your example. > > first, I don't think your example is a good example. > > b1: m1,m3 > b2: m1,m2,m4 > b3: m1,m2,m4 > > 1) if a recover writer proceed writing m4, it means m2 and m3 should be > replicated to fully-replicated during ledger recovery. > 2) based on current read policy, I don't think two client would different > sequence. > > secondly, still use your example for the concern about LR+1 entry (ack > quorum size 2). > > client 1 wrote entries m1 - m4 asynchronously. m1 and m2 acked, m3 never > wrote, m4 wrote to b1 (based on the current implementation, m4 could go > before m3). > > b1: m1, m4 (c1) > b2: m1, m2 > b3: m1, m2 > > client 1 failed. client c2 came in and recover the ledger to m2. c2 wrote > m3 and m4 and failed. > > b1: m1, m4 (c1) m3 > b2: m1, m2, m3, m4 (c2) > b3: m1, m2, m4 (c2) > > client 3 came in and recover, encountered two different entries added by > different clients. but as I explained before, if we have an incrementing > session id for each writer, it is easy to distinguish m4 in b1 and m4 in b2 > & b3, since they are added by different sessions. > > > > On Tue, Jan 22, 2013 at 11:31 AM, Flavio Junqueira > <[email protected]>wrote: > >> No, I didn't mean a recovering writer, I meant a client reading the >> content of the ledger. Focusing on closing and recovering only, I agree >> with your example. I'm trying to make the point, though, that if we allow >> multiple regular writers to a ledger over time, then we will end up in >> trouble. I believe that's the case, but apparently you guys don't, so we >> need to convince ourselves one way or another. >> >> I'd like to know if the following execution is possible in the case that >> we have multiple regular writers. A recovering writer (soon to become a >> regular writer) replicates m2 to an ack quorum and after completing ledger >> recovery it writes m4 to an ack quorum, leaving the ledger in the following >> state: >> >> b1: m1,m3 >> b2: m1,m2,m4 >> b3: m1,m2,m4 >> >> After writing M4, the writer closes the ledger. Two clients that come and >> read this ledger can now read one of the two: >> >> 1- m1 m3 m4 >> 2- m1 m2 m4 >> >> Is this case not possible? If so, what prevents it from happening? >> >> -Flavio >> >> >> On Jan 22, 2013, at 6:37 PM, Ivan Kelly <[email protected]> wrote: >> >>> On Tue, Jan 22, 2013 at 05:50:50PM +0000, Flavio Junqueira wrote: >>>> I'm not sure it is fine, one reader could read m3 fine while another >>>> can read m2 fine for the same id. >>> I assume by reader you mean recovering writer. A reader cannot see m3 >>> until the ledger has been closed or recovered, as LAC will never >>> return m3 until it has written to an ack quorum. >>> >>> In the case of 2 recovering writers, r1 and r2 >>> >>> b1: m1,m3 >>> b2: m1,m2 >>> b3: m1,m2 >>> >>> if r1 sees m3, then it will replicate to an ack quorum before >>> proceeding, in the following steps. >>> 1. write session fence id to zk >>> 2. send fence id to each ack quorum >>> 3. read m3 >>> 4. write m3 to ack quorum >>> >>> if r2 comes in before 1, then r2 will not be able to proceed. >>> if r2 comes in before 3, then r1 will not be able to proceed. >>> >>> -Ivan >> >>
