I took a quick stab at a fix for the transaction lookup problem. I will create a related jira for this issue, so that we can track it and resolve it for Seam 2.1.1. All of the JNDI requests for UserTransaction go through the org.jboss.seam.transaction.Transaction class (see : http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/transa...). This is an event scoped component so its lifecycle covers the entire request from RESTORE_VIEW through RENDER_RESPONSE. I modified it (see attached patch file) so that it stores the result of the transaction lookup (UserTransaction, EjbTransaction, or NoTransaction). It then returns this result the next time a transaction is requested. This drastically cuts down the number of JNDI lookups. For the wiki user forum front page the number of lookups went from 114 to 6!! One at the very start of the RESTORE_VIEW phase. Then the 5 others are after the REDER_RESPONSE phase. I'm assuming because of ajax related calls for caching. I ran this change through the 25 and 50 user performance runs and saw a small increase in performance, but I have not yet investigated the details in the profiler to determine exactly where we are spending the time now. I would guess that we are not not blocking as heavily on the InitialContext lookups, but instead are passing through that code quickly and hitting further blocks, or processing bottlenecks in the persistence layer. I looked a bit at using synchronizations in an attempt to clear the stored value if the transaction is completed during the event scope but I ran into some issues with that. The current approach seems to working fine, and the wiki behaves normally, but I wanted to get some more opinions on this What is the risk of caching this transaction instance in the event scope? How can we determine when/if the transaction is not valid anymore - do we need to? Does the behavior need to be different for UTTransaction vs CMTTransaction? Thanks, Jay -- blog: http://in.relation.to/Bloggers/Jay