I have an option that holds “version numbers” with timestamps. Meaning, at some point the option containing an array gets read, an item is added to the array, and the option gets written back via update\_option.
Usually, there’s days to weeks between single entries, but lately I’ve noticed that in some instances it wasn’t triggered for a while and when I corrected that, it tried to perform multiple action in a row – those that it hadn’t done yet. Basically this:
do_something();
update_version(1);
do_somethingelse();
update_version(2);
do_yetanotherthing();
update_version(3);
While the actions themselves (do\_… in the code example) were performed, only the last “version” was logged, so just “3”. As far as I’m aware, there’s no speed limit to update\_option. But could this be some sort of race condition like the last reading and appending before the earlier ones were written, resulting in the others getting lost?
The effect vanished when I added a simple sleep(1) at the end of the update\_option() function. But that is like voodoo – I want to know what’s going on. Any ideas?
[ad_2]