When you go save the node you have to compare your copy to the original copy (in my scheme). So this is when you'd notice the problem. Of course you have the same problem now because I haven't fixed anything yet.

But you made it sound like having a unmodified copy in the shared memory would help with my changes so I said why that wouldn't do any good. Adding an inter-process node cache where I can't make use of the separate copy means that we'd have a database, two inter-process node caches, and then extra copies of nodes in each process as well. Being able to efficiently track changes to fields pretty much requires a node cache in each process. So adding another cache doesn't make sense if we do that.

Locking a node for the duration of the rendering of the HTML page would cost way too much concurrency. Delineating smaller transaction windows for such locking requires a "get node for update" feature be manditory.

Transition to such would be a huge pain. The only way I see that working is to make it optional and detect and warn when you don't use it and also detect when changes were made outside of the requested window. That requires pretty much what I'm proposing in my changes.

So the node cache needs to be revamped as I've outlined and incremental updates optimized. After that has happened, we can look at doing more drastic changes, but I'm not convinced they will be worth the effort at that point.

                - tye