Yep. Standard race condition in the base Everything node cache. If someone votes for one of your nodes at the same time as you click "I've checked all of these", then you can have two separate mod_perl processes trying to update the Aristotle node at the same time.
Even though the other process only wants to change one field in the Aristotle node (your XP), the way the Everything node cache works, that process tells MySQL to update every single field of your node (include rewriting the contents of your home node, your scratch pad, and all of your user settings). So if the other process ends up rewriting your user settings record after your mod_perl process has already rewritten it (with the new Newest Nodes timestamp) but not so much later that it starts the update after your mod_perl process has updated the 'version' number for you node, then your changes to the timestamp get overwritten.
Note that this design also degrades site performance. I have a (rough) design that improves performance quite a bit (adds one bit of load on the web server in exchange for reducing another bit of load on the web server along with reducing a lot of load on the network and the database server -- and we can add more web servers so this is a good trade-off). Exactly how to do the trade-offs for speed, memory consumption, etc. in the details of this design will be a bit tricky. And it won't eliminate the race condition. It will just greatly reduce the odds of the race condition happening since it will instead require that two separate mod_perl processes try to change the same field of the same node at nearly the same time before the problem can appear.
But I doubt I'll have the time to even start working on this change for quite a while. So try not to write nodes that people are likely to vote on if this type of thing bothers you a lot. ;) /:
Other possibilities include separating out the types of things other people change about you from things you change about yourself so that the impact of the race condition is greatly lessened. It would be a bit strange to have your XP stored in a node separate from your user node, but that would probably be a very good idea (you, the user, wouldn't really notice much difference, of course). But the work involved probably isn't enough less to warrant doing things this strange of a way (because we'd also need to separate out the reputation of a node into a separate node, which would make a huge impact on the data base).
Those wanting to work on this problem in my stead need to study Everything/NodeCache.pm (this link will only work for people who are already members of pmdev -- others would need to download v0.8 of the Everything engine to see the contents of that file). The basic idea is to store an extra copy of each node in the cache. Then updates only send (to the database) the fields that changed between the original, unchanged (hidden) node in the cache and the changed copy that was previously fetched from the cache. For large fields like node text, something tricky should probably be done to reduce the extra memory required. I have a few ideas here but none that I'm sure will work well.
- tye (vote early, vote often, it keeps you in top race condition)In reply to (tye)Re: Last checked flag not updating?
by tye
in thread Last checked flag not updating?
by Aristotle
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |