Thank you for answer.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4263415#4263415
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4263415
___
jboss-user mailing list
Ah, you're right; JBC internally implements putForExternalRead with a tx
suspend, because the semantic of that operation is to not hold locks beyond the
scope of the method call.
Sorry, I don't see any workaround to this problem. The putForExternalRead call
is fundamental to how Hibernate
bstansbe...@jboss.com wrote : JBoss Cache doesn't suspend/resume the
transaction; it's Hibernate's integration with JBC that does this. If JBC sees
an active transaction it will hold a lock on data in the cache until that tx
commits. There are times when it's incorrect for those locks to be
JBoss Cache doesn't suspend/resume the transaction; it's Hibernate's
integration with JBC that does this. If JBC sees an active transaction it will
hold a lock on data in the cache until that tx commits. There are times when
it's incorrect for those locks to be held for that long, so Hibernate
