openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Locking in AbstractBrokerFactory
Date Mon, 29 Jan 2007 01:28:35 GMT
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 <plinskey@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
> >
>

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