Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 51091 invoked from network); 22 Feb 2007 20:25:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Feb 2007 20:25:27 -0000 Received: (qmail 6277 invoked by uid 500); 22 Feb 2007 20:25:34 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 6259 invoked by uid 500); 22 Feb 2007 20:25: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 6250 invoked by uid 99); 22 Feb 2007 20:25:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Feb 2007 12:25: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, 22 Feb 2007 12:25:25 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7CEC271408A for ; Thu, 22 Feb 2007 12:25:05 -0800 (PST) Message-ID: <11302997.1172175905493.JavaMail.jira@brutus> Date: Thu, 22 Feb 2007 12:25:05 -0800 (PST) From: "Patrick Linskey (JIRA)" To: open-jpa-dev@incubator.apache.org Subject: [jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. In-Reply-To: <2238764.1171567625518.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-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475155 ] Patrick Linskey commented on OPENJPA-151: ----------------------------------------- Another would be to add a new getEnhancementContractVersion() method to the PersistenceCapable interface. This would cause immediate breakage of the old classes, since they don't have that method, and allow us to detect other subtle behavior changes in the future by checking that the version is compatible. > Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: OPENJPA-151 > URL: https://issues.apache.org/jira/browse/OPENJPA-151 > Project: OpenJPA > Issue Type: Improvement > Components: kernel > Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar > Attachments: diff.txt > > > Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. > This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: > 1. class A has one-to-one relation to class B > 2. an instance a of A is related to b1 of B. b2 is another instance of B. > 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. > 4. in the remote process a* is associated with b2* > 5. a* is merged to the original process. > The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. > The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not > serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. > Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.