Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 37679 invoked from network); 29 Nov 2007 12:44:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Nov 2007 12:44:08 -0000 Received: (qmail 77948 invoked by uid 500); 29 Nov 2007 12:43:55 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 77911 invoked by uid 500); 29 Nov 2007 12:43:54 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 77882 invoked by uid 99); 29 Nov 2007 12:43:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Nov 2007 04:43:54 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED 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, 29 Nov 2007 12:44:05 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id BE380714211 for ; Thu, 29 Nov 2007 04:43:43 -0800 (PST) Message-ID: <19100874.1196340223775.JavaMail.jira@brutus> Date: Thu, 29 Nov 2007 04:43:43 -0800 (PST) From: "Christiaan (JIRA)" To: dev@openjpa.apache.org Subject: [jira] Commented: (OPENJPA-441) Memory increase when deleting objects In-Reply-To: <6635632.1194948290611.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-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546703 ] Christiaan commented on OPENJPA-441: ------------------------------------ Patrick, in org.apache.openjpa.jdbc.sql.RowImpl the generated sql is cached in _sql. When dealing with many objects of the same type in one transaction all having a similar modification (eg. they are deleted or a field is updated) there is quite some memory overhead for caching this sql, since each object (or RowImpl) caches the same sql. In the attached sql it basically comes down to 2 sql statements which are duplicated many times. I think there are two options to improve this: 1) reuse the sql instead of duplicating it 2) not cache it, possibly in certain conditions eg, when many objects of the same type are involved, but generated it each time it is needed; Option 2) is probably the most straight forward. The caching is probably done for a reason but I wonder if generating the sql when needed has that much performance impact? > Memory increase when deleting objects > ------------------------------------- > > Key: OPENJPA-441 > URL: https://issues.apache.org/jira/browse/OPENJPA-441 > Project: OpenJPA > Issue Type: Bug > Affects Versions: 1.0.0 > Environment: Kodo 4.1.4, JDK 6, ms sql server 2005, JTDS 1.2 > Reporter: Christiaan > Attachments: results.ZIP, TestCaseMemoryAndDelete.zip > > > This isssue is based on issue: > http://issues.apache.org/jira/browse/OPENJPA-439 > When executing a delete on objects which all have been loaded into memory, the memory usage is doubled when calling pm.deletePersistentAll(). > The same testcase can be used which is attached to the linked issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.