[wp-trac] [WordPress Trac] #61296: Add "force" parameter to get_option and get_transient
WordPress Trac
noreply at wordpress.org
Fri Sep 6 02:15:03 UTC 2024
#61296: Add "force" parameter to get_option and get_transient
-----------------------------------------+------------------------------
Reporter: juvodesign | Owner: (none)
Type: enhancement | Status: reopened
Priority: normal | Milestone: Awaiting Review
Component: Options, Meta APIs | Version:
Severity: normal | Resolution:
Keywords: has-patch reporter-feedback | Focuses:
-----------------------------------------+------------------------------
Comment (by azaozz):
> The database is the sole source of truth, while cache is not reliable
That may be true in many cases however retrieval of options in WP works a
bit differently. All (autoload) options are loaded early and are kept in
memory. When used, all option values are read from that memory cache. When
an option is changed or deleted, it is updated in the memory cache at the
same time. There is also a nooptions cache for options that don't exist or
have been deleted. So the memory cache works as the "trusted source".
> Database changes that do not propagate immediately is not really
something that can be supported anyways.
Right. Using memory cache is a workaround for that limitation?
> In normal HA setups, the replication delay does not affect the master's
ability to mutate the state immediately.
I'm not an expert but thinking this my have something to do with
(internet) re-routing requests to different data centers?
> When process A and B start running at the same time and A changes data
of a transient while B also already read that same transient
Frankly I'm not sure if there can ever be 100% guarantee that B will get
the data set by A. My guess would be that if both A and B are part of the
same WP install, using external memory cache (memcache?) would be the best
option and would get as close to the 100% as possible.
In all other cases there will likely be some lag: DB replication, internet
trunk routers re-routing some request, busy/slow server somewhere, etc.
Consider the following example scenario:
Time 0: Action Scheduler initiates Process A and Process B asynchronously.
Time 1: Process B reads transient 'X' with value '100' and caches it in
memory.
Time 2: Process A modifies transient 'X' to value '200'. The transient is
saved to the DB in the Huston datacenter.
Time 3: Process B continues execution, and requests the DB value for
transient 'X' from the Tokyo datacenter.
Time 4: Process B calls get_transient('X'), which returns the value '100'
instead of the updated value '200' as the DB value in Tokyo was not yet
updated from the Huston datacenter when it was retrieved.
Think the same scenario would have worked properly if options/transients
were stored in memcache (and would have been way faster).
Also see the changeset and ticket @peterwilsoncc linked above, and
especially this comment:
https://core.trac.wordpress.org/ticket/31245#comment:99.
> the default behavior caused the in-memory caching mechanism of WordPress
to contain old data.
This sounds like a bug. If you can reproduce it reliably please post the
exact steps.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/61296#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list