Caching of options

Hello!

Not sure this is the place but since posting in “WP advanced” wasn’t possible I try here…

We’ve been digging around in various ways to use object cache to increase the performance of our WP-installation. We’ve found some inconsistencies in the options and after tryig various ways to store objects and various plugins to enable caching I’ve found a code snippet that doesn’t seem quite right…

In wp-includes\options.php (WP 3.4.1):
At line 135 function wp_load_alloptions goes to the database pulls a bunch of options and puts them in variable $alloptions (a quite big array that would be).

In same file:
At line 215 function update_option updates a specific option.

It does this by writing the specific option to the database but the caching code changes the option in the array and puts all of that array in the cache.

And it is the update that I think might be a problem. I speculate:
If there are multiple processes running WP there will be multiple objects $alloptions all based on what came from the database or the cache. When the update is done it is fully possible that another process that has a different version of $alloptions will later update options and write a new version (without the first change) to the cache (since not only the specific change is cached but all of $alloptions).

It might seem that all of this happens extremely quickly and these cache overwrites should be very rare. But since database/memory reads/writes are involved it is very likely that these processes run at different pace and often overlap/overtakes each other, causing the problem.

Thus a change might be invisible for a long time due to the cached object being overwritten by versions with a different change. You simply don’t know which cache write wins.

After trying commenting out functionality in our theme that updated options it seems work as expected.

Suggestion for improvement:
It would lower performance but if an option is updated the cached object should be deleted (eg: line 252 should be a wp_cache_delete instead of wp_cache_set). This would let any other process to get a fresh $alloptions on next call to wp_load_alloptions.

A different way might be to suggest using very short times for object cache, something in the range of seconds to avoid making the problem be noticed but that would also lower the efficiency of using the object cache.

Hope this makes sense, or maybe I’ve missunderstood something and all is as it should be.