[
https://issues.apache.org/jira/browse/OPENJPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468397
]
Patrick Linskey commented on OPENJPA-115:
-----------------------------------------
>From what I can tell, the locking is needed to guard the _brokers collection.
>(It is also guarding the _transactional collection, but findExisting is always
>false in the OpenJPA codebase, so that code is never used in OpenJPA.) In IMO,
>the guarding is overly-granular at best, and unneeded at worst.
The _brokers collection provides us with a means to ensure that when we close a
BrokerFactory, all open Brokers are closed along with it. Additionally, we use
a weak reference map here, so we don't need to maintain the _brokers collection
during Broker.close().
So, we have a number of options:
1. move the locking logic to be just around the code that maintains the
_brokers collection
2. implement a concurrent Collection class that uses weak references, and
eliminate all locking
3. create a configuration option (openjpa.CloseBrokersOnBrokerFactoryClose or
something) that controls whether or not OpenJPA tracks open brokers. This would
allow default behavior to be pro-active about cleanup, but also allow
containers (which are presumably doing a good job of resource clean-up) to
bypass the overhead.
> Bottleneck(s) with using OpenJPA in a Container-managed environment
> -------------------------------------------------------------------
>
> Key: OPENJPA-115
> URL: https://issues.apache.org/jira/browse/OPENJPA-115
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
> Priority: Critical
>
> Running some benchmarks against OpenJPA using the Sun Java System (SunOne)
> application server. Under load, we're not able to push the cpu to 100%. The
> culprit seems to be the lock and synchronization processing within
> AbstractBrokerFactory.newBroker(..). According to sections 5.9.1 and 5.9.2
> in the JPA specification, it looks like OpenJPA is attempting to do too much
> management of the created EntityManagers. Within a Container-managed
> environment, the Container takes care of the lifecycle of the EntityManagers.
> So, there does not seem to be a need to do the findBroker(..) invocation,
> nor is there a need to keep track of the created EntityManagers (_brokers) so
> that they can be closed when the Factory is closed.
> Once we have verified these changes, there may be others that are needed.
> But, we have to get by this bottleneck first before going to the next layer...
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
