[jira] Commented: (OPENJPA-115) Bottleneck(s) with using OpenJPA in a Container-managed environment

["Patrick Linskey (JIRA)" <ji...@apache.org>]

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