From dev-return-15909-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Mar 24 16:17:49 2010 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 88112 invoked from network); 24 Mar 2010 16:17:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Mar 2010 16:17:48 -0000 Received: (qmail 36610 invoked by uid 500); 24 Mar 2010 16:17:48 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 36587 invoked by uid 500); 24 Mar 2010 16:17:48 -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 36578 invoked by uid 99); 24 Mar 2010 16:17:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Mar 2010 16:17:48 +0000 X-ASF-Spam-Status: No, hits=-1121.0 required=10.0 tests=ALL_TRUSTED,AWL X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Mar 2010 16:17:47 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 6D871234C4E4 for ; Wed, 24 Mar 2010 16:17:27 +0000 (UTC) Message-ID: <1851378217.463361269447447447.JavaMail.jira@brutus.apache.org> Date: Wed, 24 Mar 2010 16:17:27 +0000 (UTC) From: "Pinaki Poddar (JIRA)" To: dev@openjpa.apache.org Subject: [jira] Commented: (OPENJPA-1545) Add new Detach processing In-Reply-To: <1980363623.44881267485965742.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OPENJPA-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849257#action_12849257 ] Pinaki Poddar commented on OPENJPA-1545: ---------------------------------------- The recommendation to add a version field is OK -- but what happens with this lite detachment when an entity does not use a version field? Can I merge() the object graph back when this detach lite was used with some entities without a version field? If yes, why did the test persistent entities that worked before this change without version field required addition of a version field? If no, how does that discrepancy manifest in the user application code -- does this new mechanics detect and raise an exception when it meets an unversioned entity -- or does such usage violate data integrity silently? Do we have a test that shows such behavior? > Add new Detach processing > ------------------------- > > Key: OPENJPA-1545 > URL: https://issues.apache.org/jira/browse/OPENJPA-1545 > Project: OpenJPA > Issue Type: Improvement > Components: performance > Affects Versions: 2.0.0-beta2 > Reporter: Rick Curtis > Assignee: Rick Curtis > Fix For: 2.0.0 > > Attachments: OPENJPA-1545.patch > > > There have been a number of mailing list posts where the net of the post is that someone doesn't want OpenJPA to detach their Entities because after the commit happens, then are all going to be gc'd. All of the detach processing ends up being a waste. I also observed this same behavior when running some performance tests. > With this JIRA I'm going to add a new openjpa.DetachState configuration option which will enable a new, super fast, minimalistic detach approach. This change is targeted at detach processing that happens due to an AutoDetach. Explicit detaches(ie: em.detach(..) ) will work as they always have before. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.