First of all, the documentation would deserve an update, given that it is still mentioning Hibernate 3.5 while 4.x branch is already at the end of maintenance cycle and you should definitely use version 5.0, which contains a lot of bugfixes wrt 2LC (see Infinispan: Hibernate Second Level Cache improvements). If you use 4.x, expect occasional stale reads.

Anyway, the replicated-entity cache means that the updates will be replicated as key+value (as you're used to with replicated cache). Caching DB reads, on the other hand, uses special flags to keep the update local only. That way, you end up with nulls on one node and actual value on another - but that's safe wrt consistency with DB.

In 4.x: When you execute INSERT INTO xxx VALUES (...), in replicated cache the value will get to the other nodes. Only when you do SELECT x FROM xxx, the cached result gets written only locally.

In 5.0: When you use non-transactional replicated/distributed cache, in fact it replicates the cached result to other nodes, too. It was meant to work only locally as in previous version, but due to the way how Infinispan uses locking, it does not work and it's replicated to the other nodes as well. However, if it encounters a lock on any node, the update immediately silently fails instead of waiting for the lock.

Version of Infinispan used in WF for session replication is probably different from what ORM uses. AFAIK WF 9 uses Hibernate 4.3.x, and that was compiled against Infinispan 6. Albeit, it's possible that they're actually running Hibernate 4.3.x against 7.2.3 - WF 10 uses Hibernate 5.0.x with Inifinispan 8.0.x, although 5.0.x is still compiled against Infinispan 7.2.x.

So, looks like you use 4.3.