[
https://issues.apache.org/jira/browse/OPENJPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468429
]
Patrick Linskey commented on OPENJPA-115:
-----------------------------------------
Recall that we do have a 1.4-compatible concurrent collection at
org.apache.openjpa.lib.util.concurrent.ConcurrentHashSet. However, to my
knowledge, that impl uses hard references.
> 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.
