Well Flavio, it is a extremely simple prototype where a primary broadcast updates on a single integer to backups. So we gonna have (n-1) reads for every write in a cluster of size n. I think sequential nodes in Zookeeper are fine for now, But I don't know if I am going to review that if things begin to get more complex.
Tks a lot, André Oriani > Hi Andre, To guarantee that two clients that read from a ledger will > read the same sequence of entries, we need to make sure that there is > agreement on the end of the sequence. A client is still able to read > from an open ledger, though. We have an open jira about informing > clients of the progress of an open ledger (ZOOKEEPER-462), but we > haven't reached agreement on it yet. Some folks think that it is best > that each application use the mechanism it finds best. One option is > to have the writer writing periodically to a ZooKeeper znode to inform > of its progress. > > I would need to know more detail of your application before > recommending you to stick with BookKeeper or switch to ZooKeeper. If > your workload is dominated by writes, then BookKeeper might be a > better option. > > -Flavio > > On May 19, 2010, at 1:29 AM, André Oriani wrote: > >> Sorry, I forgot the subject on my last message :| >> >> Hi all, >> I was considering BookKeeper to implement some server replicated >> application having one primary server as writer and many backup >> servers >> reading from BookKeeper concurrently. The last documentation a I had >> access says "This writer has to execute a close ledger operation >> before >> any other client can read from it." So readers cannot ready any >> entry on >> the ledger, even the already committed ones until writer stops >> writing to >> the ledger,i.e, closes it. Is my understanding right ? Should I >> then use >> Zookeeper directly to achieve what I want ? >> >> >> Thanks for the attention, >> André Oriani >> >> >> >> >> >> > >
