[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