I encountered a scenario that illustrates this issue - I've an entity for which the region name was declared to be "a.b.c" and at runtime a query is marked cacheable and assigned to the same region name. Because the entity region is transactional (concurrency strategy) the query result cache winds up transactional as well (though query cache should not be transactional). This causes unexpected failure when updates to the region for the query are scheduled to occur during commit ... if the key is locked when the update is attempted, the update (which is configured for fast-fail) fails the commit and forces rollback.