This lets callers use adaptive TTLs on the near-expiration
preemptive refreshes if the new and current values match,
using the as-of time as $mtime.
Change-Id: Ie541c35f890c9f789d1accf9f2a43506daaf31f0
This lets callers have their own process cache but keep it
managed in a central location, making it easier to reset
when DB transaction snapshot are flushed or when unit tests
want to clear caches between runs.
Use this to replace the Revision text process cache.
Change-Id: Ic61ee9140d4ce9836cc4650adb5bb75a291fea18
Callers using wfTimestamp( TS_UNIX, ... ) where getting $minTTL
due to the output being a string number.
Change-Id: I6b67a941940f40ef9a543f11d0dbccacafaaa53b
* This better handles delayed/lost cache purges by
having lower TTLs for entries that often changes.
* Use this for foreign upload description page caches,
we purges are never received from the source wiki.
* Also use this for User and LocalFile cache TTLs.
* Also move the Database::getCacheSetOptions() call in
User *before* doing the queries, which is preferred.
* Fixed some IDEA errors too, like the undeclared
mApiBase field.
Change-Id: I70f8ebb29ac853c2a530d9eedb9e7facc1b7b710
* Update documentation about relay methods.
* Change interim key set() to add() to avoid broadcasting it.
* Remove the behavior of doing purges synchronously in the
local DC first before relay. In both the event relayer and
mcrouter case, they will be asynchronous. It was hardly
even possible to use such behavior since loads come from
slave DBs, which do not see changes right after COMMIT.
Bug: T97562
Change-Id: I7759c82ae6e1b72fc227882a99c9a712a46374f6
This is useful for avoiding stampedes in the one case that lockTSE
does not alone cover, which is when the key does not exist or is
tombstoned.
Also avoid saving interim values unless the key is tombstoned
since there is no point in doing that otherwise.
Change-Id: I70997e90217a0979e0589afa7a5107b0e623c7cf
* getWithSetCallback() takes a 'version' parameter.
* If the value at a key has a different version, then
getWithSetCallback() will automatically use a separate
key. Which value "wins" the main key does not matter.
* Purges are handled by using the main key as a sort of
check key (with no hold-off). Note that this key is always
purged on delete().
* Changed stash keys to track the same info as other keys
both for consistency and because this change needs the
generation timestamp. Renamed the stash prefix to avoid
corrupt results with Het Deploy.
* This is useful for things like the User class that use
versioning and have cross-wiki key access and purges.
Currently, bumps to version must be deployed to all wikis
at once, which this aims to avoid.
Change-Id: I26ae62f116e32b48bcf06bc13f8b9e79ae976745
If a set() happened around the exact same time as check key was
initialized via get(), the curTTL in future get() calls could
sometimes be 0 instead of a negative value, even though hold-off
should apply.
Change-Id: Ide1fd65112aff425a4798e2ec406d71f2a8e84a7
To allow batch queries for multiple keys that themselves have different check
keys. Previously check keys always applied to all keys being retrieved.
Change-Id: I9e5ba198d79020ce05a802a510762e29fcfb2f1b
* Keys that take a long time to generate would run into
the MAX_SNAPSHOT_LAG check and have set() no-op. This
would be fine except that leaves no key there to figure
out the time since expiry and therefore whether to use
the mutex, so it didn't. This now saves the keys but with
a FLG_STALE bit set, making the next caller that sees it
perform a regeneration (unless it can't get the mutex).
* Bumped LOCK_TTL so that keys can stay locked much longer.
* This is easy to test via sleep(5) in tagUsageStatistics()
and two Special:Tags browser tabs.
Bug: T91535
Change-Id: I549e70ace3d2e7da40d3c4346ebacc36024cd522
* In the common ~0 second lag case, transactions up to ~7 seconds
long will have normal set() behavior (instead of just ~5 seconds).
* Like wise with ~0 second transactions tolerating ~7 seconds of
lag (instead of just ~5).
* The lower hold-off time lets caching resume 3 seconds sooner.
Change-Id: I21e2a0a6915492cec422b6a6af5541937745c15b
