On Wed, Jan 23, 2013 at 10:14 AM, Flavio Junqueira <[email protected]>wrote:
> 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? > Yes. T is the time that fencing completes. Although I clarified in my previous email, ledger recovery operations just recover the entries added before T, I treated this operations as happened before time T for an easy abstraction of the requirements. But to make it clear here, I could split it into more phases. T is the time fencing completes. T' is the time resuming add operations. the time between T and T' is ledger recovery. the operations happened at this period just recover the entries added before T. > > > 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? > Yes. I tried to think of not adding session id to entries. but it is hard to make it work according to the two rules I mentioned. > > -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 > >> > >> > >
