[wp-trac] [WordPress Trac] #25773: can not update option in wp 3.7 and hanging in wp_clear_scheduled_hook()

[WordPress Trac]

#25773: can not update option in wp 3.7 and hanging in wp_clear_scheduled_hook()
--------------------------+--------------------
 Reporter:  dimagsv       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.7.2
Component:  Cache         |     Version:  3.7.1
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by dd32):

 > 4. Cron job in the new thread clear event 'sm_build_cron' from database
 earlier than wp_clear_scheduled_hook() called in the main thread.
 > 5. Event 'sm_build_cron' exist in the main thread memory cache, but not
 in the database.

 So we've got 2 bugs here, based around the same thing,
 1. If `wp_clear_scheduled_hook()` has been run in another thread,
 `wp_clear_scheduled_hook()` will endlessly loop in the current thread,
 because:
 2. `update_option()` may now fail in "high-traffic" situations where an
 option is being updated my multiple threads to the same value.

 There's multiple fixes:
 1. Revert [25664], but that has the disadvantage that a DB write failing
 will still end up in the cache
 2. make `wp_clear_scheduled_hook()` not rely upon `wp_next_scheduled()`,
 resulting it only trying to unset/save once-per-event rather than looping
 (because the cache says it's still there after "clearing" it)
 3. make `wp_next_scheduled()` bypass the cache when it calls
 `_get_cron_array()` so that it's always got the latest data from the DB,
 downside that it's not as performant
 4. make `wp_clear_scheduled_hook` aware that `wp_unschedule_event()`
 failed (but that also means making `wp_unschedule_event()` aware that
 `_set_cron_array()` can fail, and making `_set_cron_array()` aware that
 update_option can fail)
 5. In the event that `update_option()` fails, populate the local cache
 with fresh data from the DB - this is technically possible, but also
 potentially weird, in that update_option might fail due to a DB issue, and
 then read stale data from a slave DB, or another write between the
 attempted write and the read causes the value to change to another one.

 It's a tricky situation, as WordPress generally relies upon the fact that
 data it's using won't be altered outside of the current thread while it's
 using it.. which is a really bad operating assumption to make.

 A unit test might be hard for this scenario, but should be able to
 replicate it by modifying the DB directly..

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25773#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software