Found it, sort of. The SELECT FOR UPDATE was being caused by he DB (Postgres). It uses a SELECT for UPDATE on Referential Integrity (RI) links. The has the side effect of an insert on (say) a transaction table to lock all related tables. The side effect of that is a SEVERE drop in throughput (only one at a time).
Solution? Upgrade to Postgres 8.1. It handles locking for RI differeht by introducing a UPDATE FOR SHARE which uses a shared lock rather than an exclusive one. As for deadlocking - still it is REPEATABLE_READ that is the culprit. I'd recommend that the default is change away from this to READ_COMMITTED. Much safer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3913225#3913225 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3913225 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
