* 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
Add new 'reportDupes' parameter to BagOStuff. This parameter enables scheduling
of a callback after the current web request ends. This callback will emit warning
log messages for all keys that were requested more than once.
The default ObjectCache factory for MediaWiki enables this option by default.
Not by default for plain BagOStuff instances, however. E.g. `new HashBagOStuff()`.
It also set 'asyncHandler' for all classes now (not just MultiWriteBagOStuff).
Bug: T128125
Co-Authored-By: Timo Tijhof <krinklemail@gmail.com>
Change-Id: I8a2b06cf54d2acf5950eed71756ecdf50e224be1
Ie161e0f was done in a hurry, and so didn't do things in the best ways.
This introduces a new "CachedBagOStuff" that transparently handles all
the logic that had been copy-pasted all over in Ie161e0f.
The differences between CachedBagOStuff and MultiWriteBagOStuff are:
* CachedBagOStuff supports only one "backend".
* There's a flag for writes to only go to the in-memory cache.
* The in-memory cache is always updated.
* Locks go to the backend cache (with MultiWriteBagOStuff, it would wind
up going to the HashBagOStuff used for the in-memory cache).
Change-Id: Iea494729bd2e8c6c5ab8facf4c241232e31e8215
* This can happen due to incr/add races. Use incrWithInit()
instead to handle such cases.
* Also made BagOStuff:incrWithInit() return the new value like incr().
Change-Id: I0e3b02a4cff7c20544a9db2eaabd3f61e5a470b1
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
* Match behaviour of MapCacheLRU and ProcessCacheLRU.
* Add missing unit tests for TTL and maxCacheKeys eviction behaviour.
Change-Id: I559eae1cd336274b21728e86775cfbad7e2f2c6d
Follows-up 7cddc22.
Also use PHPUnit_Framework_TestCase as parent instead of MediaWikiTestCase
in preparation for library extraction.
Change-Id: I0e68e56ecf8376b52a59c33ba6dd18b671bdcfc9
* 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
