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