It's impossible to implement a cache provider based on the Javadoc and get a working system. Here's one example (READ_WRITE concurrency, as that's what I'm targeting):

1. Joined entity is merged.
2. Before writing to DB, EntityUpdateAction locks the cache item.
3. Oh no, we can't update the cache because the entity spans multiple tables and concurrent updates are possible without violating ACID! Call ERAS.remove() which is a no-op for READ_WRITE.
4. After commit call ERAS.unlockItem(). According to the documented behavior of ERAS we are now inconsistent.

EHCache maintains consistency by deleting the item...sort of. Afterwards the region contains an unlocked lock, which acts almost like a cache miss except, I suppose, for some weird flows involving re-locking. It doesn't help in this case because any lock on the item is only going to lead to an unlock, not an update. The important thing for consistency is that a later get will miss.

This is just one example of a way the cache SPI in woefully under-documented (or just plan wrong!). As it is, the only possibility for creating a correct implementation is to get 12 feet deep in hibernate-core and hibernate-ehcache to get at the real cache semantics.