Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 32986 invoked from network); 12 Mar 2010 16:34:27 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Mar 2010 16:34:27 -0000 Received: (qmail 8873 invoked by uid 500); 12 Mar 2010 16:33:50 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 8796 invoked by uid 500); 12 Mar 2010 16:33:50 -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 8788 invoked by uid 99); 12 Mar 2010 16:33:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 16:33:50 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED 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; Fri, 12 Mar 2010 16:33:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 1F3F6234C4BE for ; Fri, 12 Mar 2010 16:33:27 +0000 (UTC) Message-ID: <712944443.229101268411607123.JavaMail.jira@brutus.apache.org> Date: Fri, 12 Mar 2010 16:33:27 +0000 (UTC) From: "Pinaki Poddar (JIRA)" To: dev@openjpa.apache.org Subject: [jira] Created: (OPENJPA-1567) Can we relax strict group like behavior on persistence context? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org Can we relax strict group like behavior on persistence context? --------------------------------------------------------------- Key: OPENJPA-1567 URL: https://issues.apache.org/jira/browse/OPENJPA-1567 Project: OpenJPA Issue Type: New Feature Reporter: Pinaki Poddar JPA imposes a strict group-like behavior on a persistence context. If x is managed by a persistence context C then, any instance y reachable from x has to be managed by C as well. Even if y is being accessed only by reference in context C. JPA Specification version 2.0 Section 3.2.8 "It is the responsibility of the application to insure that an instance is managed in only a single persistence context. The behavior is undefined if the same Java instance is made managed in more than one persistence context." The actual wordings of "undefined", however, leave some possibility of y being managed by context C1 while being referred by another x managed in context C2. The primary motivation to allow traversal (only by reference) from x to an instance y managed by another context are a) to support a more natural use case for merge() where y may not be managed by C bout nor is y modified by the merge operation b) reduce detach cost (which remains the only current way to support use case (a)) Opening up this issue for a discussion.... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.