I have attached a tests case showing that with merge, where the entity in the 2nd cache is old compared to the one in the unit of work it's not getting invalidated.

Will happen in couple of scenario, for example in cluster, where invalidation/changePropagation is broken or too slow, the application may receive an object with the most recent version from JMS, DB VIEW, or UI that was rendered from an different node having the right version.

A check to see which version is most recent (2nd level cache or unit of work) should happen to decide to invalidate or not the 2nd cache entity. That optimization work with version and timestamp but not the 'full object compare' approach that support also optimistic lock.

I personally care about getting this fixed because we have a strategy where we cache each node but don't actually have nodes communicating, we then 'fix' the cache when we run into stale issue below the scheduled refresh.