[
https://issues.apache.org/jira/browse/ZOOKEEPER-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017177#comment-13017177
]
Flavio Junqueira commented on ZOOKEEPER-1001:
---------------------------------------------
Hi Rob, No problem at all!
{quote}
If I ask a bookie for record M, either the bookie has the record or doesn't
have the record. Regardless, the bookie has a greatest record N, and let
X=N.lc. Now record N may not be committed, but record X is committed. And so
the bookie can return not only record M, if available, but also a flag
indicating whether X≥M. If my bookie returns M but X<M, I can wait a little bit
and ask again. If the writer agrees that the difference between N and N.lc is
bounded, won't a reader with just a little patience (the expected time between
M and N.lc≥M) continue to make progress? Making progress is the goal, not
knowing the very last committed record. And you can't know the last committed
record until the ledger is closed, in any case.
{quote}
Sure, we have an equivalent feature implemented in bookies today. If I send a
request to some bookie to read an entry from a given ledger and the entry id is
-1, it will return the id of the last committed write it knows about (we have
called it confirmed writes so far, and not committed). The bookie learns of
committed writes through regular writes, since one of the fields of the write
request is the "last confirmed hint", which is the last confirmed entry the
client writer has.
Using the hint is actually one of strategies I suggest in the very first post
of this jira. I think it is a good approach too, and might simply require
exposing it to the application.
> Read from open ledger
> ---------------------
>
> Key: ZOOKEEPER-1001
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1001
> Project: ZooKeeper
> Issue Type: New Feature
> Components: contrib-bookkeeper
> Reporter: Flavio Junqueira
> Attachments: zk-1001-design-doc.pdf, zk-1001-design-doc.pdf
>
>
> The BookKeeper client currently does not allow a client to read from an open
> ledger. That is, if the creator of a ledger is still writing to it (and the
> ledger is not closed), then an attempt to open the same ledger for reading
> will execute the code to recover the ledger, assuming that the ledger has not
> been correctly closed.
> It seems that there are applications that do require the ability to read from
> a ledger while it is being written to, and the main goal of this jira is to
> discuss possible implementations of this feature.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
