Version 43 by mikew
on Jul 30, 2012 12:55.

compared with
Version 44 by ingenthr
on Oct 10, 2012 19:23.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (1)

View Page History
Note that the status OBS_MODIFIED does not indicate monotonic forward mutation. For example, in one scenario a failover may have occurred and the item key "foo" being observed may have been reverted to a previous state. This state may even be some value prior to the initial fetch before the application code mutated the value of the document.

h4. Recommendations to Clients on Polling

Client libraries will generally implement new forms of operations where application code expresses it's desired durability as outlined above. Getting to this level of durability is something that happens within the client library through polling with the OBSERVE protocol operation.

Given that Couchbase Server may be run anywhere from a small VM on old, slow disks to running on physical hardware and thus persistence and replication can vary from below 10ms to potentially 100s of milliseconds, clients SHOULD have an adaptive algorithm that uses statistics advertised by the response from OBSERVE to guide how it polls to check for the given state.

The recommendation is for the client to initially poll once after 5 milliseconds, and then poll with increasing frequency until the average persistence/replication time is reached. Do note that the value will be 0 if the server has no information on average persistence or replication time [note: as of this writing, the stats are there for persistence time].

Alternatively, the client library MAY implement a simple loop of polling. The recommendation is that this loop is done on a 100ms interval for up to 400 iterations or 40 seconds. If the client library implements this approach, it MUST allow these values to be tuned.

h2. Implementation Constraints