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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019576#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...