anonymous wrote : | ... it would have the effect of treating Hibernate's afterCompletion() call as occuring outside the tx scope, which AFAICT is Hibernate's intent. | Yes, this is why I sent a mail to the hibernate dev mail list to clarify the intention here. If it is to run outside the current tx, this should be done explicitly. Just nullifying the tx (as per the code snippet commented out) leads to other errors (when using optimistic locking, for example - guarded by the test in invoke()). I was speaking with Kevin Conner about this earlier as well, and doing a cleanup like this in aftercompletion may lead to deadlocks too, if for example, the synchronizations haven't had a chance to release locks yet and a call to remove() blocks. I think the Hibernate usage here is incorrect as it assumes that the cache is not transactional. Perfectly acceptable for their other cache impls, but not very good for JBoss Cache. This remove() should not happen in the afterCompletion() block but in a finally{} block after the tx commits/rolls back. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028406#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...