openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject Locking in AbstractBrokerFactory
Date Fri, 26 Jan 2007 17:53:01 GMT

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.

-Michael Dick

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message