Tom, I spend quite some time on your ehcache example, and I can confirm that it's doing what you want with EHCache. I have a feeling it's a side effect of their "read-write" implementation. They lock all the entities involve with an updates, then when the Exception occur the lock stay there. When it's locked no other session can read the old entities but they can still write on top of it. At some point if no other session override the locked entity the 'normal' expiration will trigger.

1- Other side effect is that if the update was long (like batch processing (updating hundreds of row with slow trigger)), no other session could have a cache hit during that time on any of the entities involved. Instead will read from DB and end-up with same value anyway (since the other transaction is not committed), so it's a behavior that doesn't help anything. It's slightly better the other session can still read these entities in progress of been modified.

2- Any other entities involved will be locked, so by side effect invalidated in the session 2nd level cache. Even if batch update is not used (send in one statement all the updates), so one update at the time, still all entities will stay locked.