Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Message-ID: <19325141.1170098509332.JavaMail.jira@brutus>
Date: Mon, 29 Jan 2007 11:21:49 -0800 (PST)
From: "Kevin Sutter (JIRA)" <jira@apache.org>
To: open-jpa-dev@incubator.apache.org
Subject: [jira] Created: (OPENJPA-115) Bottleneck(s) with using OpenJPA in a
 Container-managed environment
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.