Hi, We've been running some multi-threaded tests with OpenJPA in a managed environment and it looks like we've hit a bit of a bottleneck. Many of the threads are waiting on the lock in AbstractBrokerFactory.newBroker().
I took a look at the code inside the lock and it looks like the main thing it's doing is managing a cache of EntityManagers. If there's a EM/Broker associated with the current transaction and its user & password (not sure why we're checking them) match then the EM is returned to the caller. I thought that the transaction to EM relationship was maintained by the container (section 5.1 of the JPA spec). At first glance it looks like we're duplicating effort, are there other reasons that OpenJPA needs to maintain the relationship between transactions and EMs? Besides this cache for the EMs, is there any reason to have a heavy lock in newBroker()? I get the feeling I'm missing something obvious here. Thanks, -- -Michael Dick
