You vote for my node and you change my XP, your XP, and your vote count. I vote for your node and I change your XP, my XP, and my vote count. Yeah, user nodes get updated simultaneously all the time. Other nodes as well.

I'm not talking about users editing the text of the same node at the same time. The few situations that support that implement more complex locking.

The problem is not that the user made decisions about how to update a node based on old data they saw. Please read the Last checked flag not updating? thread which covers this problem in more detail. Yes, you are misunderstanding. (:

The changes to the node happen during the course of rendering a page. What I need to keep track of is the state of the node between the "get node" and the "save node".

Ugh. I just realized that we have another race to deal with. You could have this happen:

• process X does "get node P"
• X changes a field in node P
• X calls a routine...
• process Y finishes an update and does "save node P"
• Y's node cache saves the changes and increments the version number of node P
• the routine X called calls "get node P"
• X's node cache notes that P's version number is old and rereads the node into the cache, clobbering the previous changes X had made
• X finishes updating and does "save node P"

So "get node P" also needs to be made smart enough to not reget the node. My first thought was to compare the two versions of the node and not reget if the node is changed. But I think a better idea is to only reget a node once per page load (more efficient, more robust). Well, I'll chew on that some more...