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 >
