Hi Jukka, > The issue shouldn't be that critical for deployments with mostly read > access, or write access happening only on a single cluster node, or > even multiple nodes writing to separate branches of the content tree. > But do we have a good picture of what will happen if multiple cluster > nodes concurrently update the same content nodes?
What happens is the following: before actually being able to store its changes, a cluster node has to "lock and sync", i.e. it must first obtain a non-shareable lock on the journal (which is either a file or a database table) and will then read all changes upto the latest revision. If one of those changes conflicts with the change this cluster node is currently trying to save, the whole update process will fail with a StaleItemException, similar to the situation when another session in the same repository would have made that change. Kind regards Dominique
