Environment: JBoss AS 4.0.5GA Configuration: All Portal version: 2.4.1 Using jboss-portal-ha.sar in a cluster We are noticing that there are quite a bit of locking problems with the JBoss Portal TreeCache. Here is one example: read lock for /org/hibernate/cache/StandardQueryCache/sql: select userinstan0_.PK as PK16_, userinstan0_.INSTANCE_PK as INSTANCE2_16_, userinstan0_.SER_STATE as SER3_16_, userinstan0_.USER_ID as USER4_16_, userinstan0_.PORTLET_REF as PORTLET5_16_ from JBP_INSTANCE_PER_USER userinstan0_ where userinstan0_.INSTANCE_PK=? and userinstan0_.USER_ID=?; parameters: ; named parameters: {userId=jplaprise(a)ascentmedia.com, instanceKey=25} could not be acquired by GlobalTransaction:<ensumapp01-01:32792>:903 after 10000 ms. Locks: Read lock owners: [] | | Write lock owner: GlobalTransaction:<ensumapp01-01:32792>:902 | | , lock info: write owner=GlobalTransaction:<ensumapp01-01:32792>:902 (activeReaders=0, activeWriter=Thread[TP-Processor1,5,jboss], waitingReaders=0, waitingWriters=0, waitingUpgrader=0) We are hardly using Portal features at all and in fact plan to remove it in the next version of our application. We are not using Portal state replication or ClusteredSingleSignOn. My question is, we have noticed that by default Portal uses REPEATABLE_READ for the isolation level for its TreeCache. What are the implications of downgrading it to READ_COMMITTED or even lower? Would this possibly eliminate the problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114769#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...