See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=152497 for the
cause of the problem with the UpdateTimestampsCache in your test.
Disabling query caching works around the problem, which can be done in your
test by adding:
| @Override
| protected boolean getUseQueryCache() {
| return false;
| }
|
The specific problem can also be addressed by using a separate cache for the
timestamps (see docs). But the general problem discussed on the forum thread
mentioned above of the possibility of lock conflicts due to lock striping
remains. However, getting the timestamps cache out of the entity/collection
cache reduces the problem to (a still significant) one of bad luck where
concurrent txs contend for the same locks rather than an inevitable situation
where changes to certain Fqns will always conflict with the lock stripe used by
the timestamps cache.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218844#4218844
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218844
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
