[ 
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.

Reply via email to