Well, high transaction may have been overshooting a little bit. What we really need is guaranteed consistency of writes. We have chosen a caching solution because we have a distributed application where reads need to be very fast and writes typically happen outside of the normal user data path (e.g. we have inventories that are collected on a periodic basis). Anyway, the scenario I describe is actually very similar to what's described here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114513 Which ultimately means that we're looking at MVCC. In the meantime I am thinking of implementing our own mutex lock within the cache itself to help synchronization across the cluster. If we do this, we can change the IsolationLevel back to something more reasonable like REPEATABLE_READ as you say. My interpretation of SERIALIZABLE is that access to a particular node would be locked when first read inside of a transaction. But this appears to happen during the commit phase and we still have contention of resources. Also, we have tried OPTIMISTIC locking but it seems to have problems with our cache loader. We use a JDBC cache loader and preload the / node. We see exceptions when the cache first initializes and tries to preload the cache. Is this a known problem? I can certainly recreate this and provide the stack trace if it helps. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155952#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...