[ http://jira.jboss.com/jira/browse/JBTM-217?page=comments#action_12369175 ] Andrew Dinn commented on JBTM-217: ---------------------------------- The short answer is no you cannot replace the map with a ConcurrentHashMap. The map in question is implemented by wrapping a WeakHashMap with a SynchronizedMap. This has different semantics to a ConcurrentHashMap -- changing it would trade off a contention problem against a garbage problem. The long answer is that thecontention is happening because of an inefficiency in the way the AS/TM code is implementing reclamation of map entries for dead transactions. A WeakHashMap works in conjunction with the GC to remove entries keyed by objects to which there are no other references (in this case the Transaction instance is the map key). So, your problem will manifest under load immediately after GC when a new local transaction is started and an update of the WeakHashMap occurs. The updating thread will lock the table and then find that a whole load of dead Transaction instances have been notified by the GC. Before it can do the update the thread has to remove the dead entries and, possibly, downsize the map table. This can take a long time and explains why the getSynchronization call in your trace is stalled The solution is for the AS/TM to make sure that the information maintained in this map is cleared out as transactions are resolved rather than relying upon the GC. I am working on a fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira