* This can avoid some stale write race conditions
* Made use of this option in a few key places
* HOLDOFF_TTL was also bumped
Change-Id: I83505a59cce0119e456191c3100f7d97bc86bdbf
* They now issue the delete() write before COMMIT of
the relevant DB (or immediately if no trx is active)
* This can avoid some stale write race conditions
* Updated the WAN cache delete() docs
Change-Id: Id54887976051120b76528070d5f2ceb357d57897
* If lockTSE is set, make sure it applies during during
the entire duration of a key being tombstoned. This lets
regenerations happen during that whole time, which lowers
the chance of seeing stale data if the DBs are lagged.
* If lockTSE is not set, do not apply tempTTL (for tomstoned keys).
If traffic is high, a stale value would usually be "stashed" and
used for 5 seconds. If the lag was only 1 second, then this
is suboptimal.
* Determine tempTTL from lockTSE as they no longer make sense
being separate. This makes things easier to understand and
also makes the lockTSE value account for the last regeneration
time (via stash key TTL). Since LOCK_TSE << HOLDOFF_TTL, this
helps avoid stale reads without adding stampede risk.
Change-Id: I3b01f0ec67935a238b30e02e42004fd3b2dcfb9d
* This still allows If-Modified-Since logic but does not
need to broadcast initialization values just because a
key fell out of cache. The value can differ between DCs
anyway via skew, this just lets them drift more. Actual
purge events are still broadcasted, which is what matters.
* The User class has now been simplified given this change.
* Added more general comments to getCheckKeyTime().
Change-Id: Ic1f4bbb1947e0d1dd47499c9e9dc86991c30580c
* Do not use lock() for tombstoned keys unless lockTSE was set
* Moved the is_callable() check down a bit further
* Also removed one inaccurate comment
Change-Id: I904e0681faa48b1dc2bc2a3c005a29d2f8347065
