#contains is (atm) only intended for use from JPA's Cache calls which happen outside the context of a Session/EM. It is essentially the same "scope" as the evict calls we have discussed in the past. These all operate "outside any transactional context" because the are called outside of any such context - and even if they are called "within a transaction" in a JTA sense that transactionality should be ignored.

I said "atm" above because we could decide to add a transactional #contains override. The intent would be very different - basically it would be an opportunity for providers to optimize the "minimal puts" case. ATM when minimal puts is enabled we perform a "get" from the cache and if we get back a non-null value we skip the put. This get needs to happen transactionally. I do not know if providers can answer "does get return a non-null value" any more efficiently via a "contains" call - but if so, we could consider adding that. I'm not sure I would call that method "contains" though - maybe "canRead"?

Also, DirectAccessRegion#contains is just a mistake. We never need to know that about query or timestamp caches - JPA does not define caching of these so does not define any way for an app to ask