openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: Locking in AbstractBrokerFactory
Date Fri, 26 Jan 2007 18:45:58 GMT
We've identified this as a bottleneck as well, but haven't gotten to a
fix for it yet.

I'm not sure whether or not the cache is necessary in the JPA case. But
in any event, the fix that we were looking at was to replace the
collection with a ConcurrentHashMap, and thus avoid the locking
altogether.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Michael Dick [mailto:michael.d.dick@gmail.com] 
> Sent: Friday, January 26, 2007 9:53 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Locking in AbstractBrokerFactory
> 
> 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
> 

Mime
View raw message