Also this:

Once an update has been applied, it will persist from that time forward
until a client overwrites the update. This guarantee has two corollaries:
If a client gets a successful return code, the update will have been
applied. On some failures (communication errors, timeouts, etc) the client
will not know if the update has applied or not. We take steps to minimize
the failures, but the only guarantee is only present with successful return
codes. (This is called the *monotonicity condition* in Paxos.)
Any updates that are seen by the client, through a read request or
successful update, will never be rolled back when recovering from server
failures.


I think that the clear implications here are:

a) if you get a successful return code and no session expiration, your
ephemeral file is there

b) if the ephemeral files is created, you might not get the successful
return code (due to connection loss), but the ephemeral file might continue
to exist (because connection loss != session loss)

c) if you get a failure return code, your ephemeral file was not created

On Wed, Jun 30, 2010 at 4:33 PM, Patrick Hunt <ph...@apache.org> wrote:

> in particular see "timeliness"
> http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkGuarantees
>

Reply via email to