BUG: Batch collection locking is broken

At least for 0.10.15, the locking in clarity-server-analytics.php‘s clarity_buffer_collect_event is broken. The idea seems to be to read and write CLARITY_COLLECT_BATCH_KEY in a transaction, but this may lead to a) database warnings and b) missed events.

If two processes run in parallel, the first might successfully run through the whole transaction. The second process will also start and try to update the option. With snapshot isolation in the database, this fails on commit, because the affected option row will have changed:

WordPress database error Record has changed since last read in table 'wp_options' for query UPDATE …

In turn, the new event will not be saved. If snapshot isolation is off, the second process instead will most likely overwrite whatever the first process wrote and either events will be lost or previous ones duplicated.

The idea could probably work if the result of $wpdb->query was checked to repeat the whole transaction if necessary. I am not sure if some option caching might interfere with that, though. Additionally, this might still lead to those database errors being reported quite often on busy sites.

It would probably be more reliable to use a custom table with one row per event and avoid options, but this will still require some form of locking.

• This topic was modified 2 weeks ago by luzat.