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#4028406
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028406
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
