Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 70072 invoked from network); 1 Feb 2007 22:48:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Feb 2007 22:48:32 -0000 Received: (qmail 54988 invoked by uid 500); 1 Feb 2007 22:48:34 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 54965 invoked by uid 500); 1 Feb 2007 22:48:34 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 54951 invoked by uid 99); 1 Feb 2007 22:48:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Feb 2007 14:48:34 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Feb 2007 14:48:25 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7FCDB7142B6 for ; Thu, 1 Feb 2007 14:48:05 -0800 (PST) Message-ID: <7528517.1170370085493.JavaMail.jira@brutus> Date: Thu, 1 Feb 2007 14:48:05 -0800 (PST) From: "Craig Russell (JIRA)" To: open-jpa-dev@incubator.apache.org Subject: [jira] Commented: (OPENJPA-115) Bottleneck(s) with using OpenJPA in a Container-managed environment In-Reply-To: <19325141.1170098509332.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469604 ] Craig Russell commented on OPENJPA-115: --------------------------------------- Yes, null checking is an expected requirement when dealing with weak references. If you can get a strong reference in a cleanup routine then it's ok to use it, because the fact that you have a strong reference will prevent garbage collection. If you get null from your weak reference, then the garbage collector has already done its job and by definition there can be nothing left for your routine to clean up. > 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.