Your understanding of how workspace cache clearing works is correct: when a session is saved successfully, a number of events containing the changes from that session are sent/broadcasted remotely via JGroups to all members of the cluster. Once these messages are received (eventually) these nodes should clear their local ws caches which means that the "next read operation" should get fresh data from the persistent store. Note that "eventually" is important here as this operation is not synchronous. So in the  [transaction.commit(), events received] interval other cluster nodes may see stale data.

As long as messages are dispatches and received correctly everything should work. You can investigate the cache clearing behavior by enabling TRACE logging and looking for the messages printed here: modeshape/WorkspaceCache.java at master · hchiorean/modeshape · GitHub . After a WS cache is cleared, the first lookup for a particular node key should retrieve a copy from the DB unless there is an active transaction which has already loaded that node. In theory this case should not be possible because exclusive locking is used (unless there's a bug somewhere). In other words, ModeShape explicitly disallows multiple transactions concurrently changing the same node(s).

In terms of the attached configuration files, the local jgroups-config.xml file looks fine to me. Note that I have no experience with WF domain mode, so I can't tell for sure if the JGroups WF configuration is ok or not. For example, I don't see the oob_thread_pool.enabled="false" thread_pool.enabled="false"  properties which are critical for correct event dispatching (but they may be 'false' by default in WF)

So first I would suggest looking at TRACE logging in the WS cache to check that the caches are cleared. The other thing you can probably test (if you haven't done so already) is a simple non-WF cluster using your JG config which should indicate if this particular issue is WF related or not.