CacheImpl.getCurrentTransaction() logs a WARN if it finds a tx associated with the thread that isn't ACTIVE or PREPARING.
Found at least one use case where this isn't valid. If a user does some sort of bulk update operation on entities (e.g. 'delete from Customer customer where customer.credit < :creditScore'), as part of afterCompletion() processing Hibernate removes all instances of the entity class. In this case the tx is Status.COMMITTED, leading to a spurious WARN.
Ways to deal with this:
1) Work around the Hibernate usage. In the integration code, these calls go through one method; here we check for a COMMITTED tx and suspend it before calling into JBC (not sure if you can suspend a committed tx). Ugly.
2) Don't warn if the tx is COMMITTED; getCurrentTransaction() just returns null. If a user wants to invoke on the cache as part of afterCompletion() work, there's nothing inherently wrong with that; it just means the call will not be associated with the tx.
3) Get out of the business of this WARN altogether. If a user wants to invoke on the cache as part of a rollback, let them. (I think this deserves the WARN, but I throw it out for completeness.)
My vote's for #2. Thoughts?
