You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Michael Dick <mi...@gmail.com> on 2007/01/26 18:53:01 UTC
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
Re: Locking in AbstractBrokerFactory
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Patrick,
Does the JDO support require the caching and the userid/password processing
in the kernel? I'm just wondering how much of this current "bottleneck"
processing is fair game to get rid of if it's not necessary for JPA.
Thanks,
Kevin
On 1/26/07, Patrick Linskey <pl...@bea.com> wrote:
>
> 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
> >
>
RE: Locking in AbstractBrokerFactory
Posted by Patrick Linskey <pl...@bea.com>.
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
>