From dev-return-6632-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Tue Oct 30 21:18:33 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 84251 invoked from network); 30 Oct 2007 21:18:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Oct 2007 21:18:33 -0000 Received: (qmail 86467 invoked by uid 500); 30 Oct 2007 21:18:20 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 86440 invoked by uid 500); 30 Oct 2007 21:18:20 -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 86431 invoked by uid 99); 30 Oct 2007 21:18:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2007 14:18:20 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [192.138.151.43] (HELO inergen.sybase.com) (192.138.151.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2007 21:18:36 +0000 Received: from smtp2.sybase.com (sybgate2 [10.22.97.85]) by inergen.sybase.com with ESMTP id l9ULI1116642 for ; Tue, 30 Oct 2007 13:18:01 -0800 (PST) Received: from atlantis-new.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id l9ULI0e08334 for ; Tue, 30 Oct 2007 14:18:00 -0700 (PDT) Received: from kokako (vpn-dub-138.sybase.com [10.22.120.138]) by atlantis-new.sybase.com (8.13.7+Sun/8.13.7) with ESMTP id l9ULHxvN001633 for ; Tue, 30 Oct 2007 14:18:00 -0700 (PDT) From: "Evan Ireland" To: References: <10024094.1193514710553.JavaMail.jira@brutus> <7056240.1193516510596.JavaMail.jira@brutus> <003501c8199d$dc20b4f0$0500a8c0@kokako> <89c0c52c0710300637s12481018h281482af59968672@mail.gmail.com> <001e01c81b2c$0aa18e50$0500a8c0@kokako> Subject: RE: Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl Date: Wed, 31 Oct 2007 10:18:09 +1300 Message-ID: <003201c81b3a$5fc5a2a0$0500a8c0@kokako> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgbOJFOrSiX7lNdRvaGle2WACHItwAAakUQ X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Virus-Checked: Checked by ClamAV on apache.org Craig, I don't believe that non-spec-compliant behaviour is permitted in the "default" configuration of any Java EE technology. > -----Original Message----- > From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] > Sent: Wednesday, 31 October 2007 10:00 a.m. > To: dev@openjpa.apache.org > Subject: Re: Byte array handling is probably not spec > compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar > objects contained in a detached Entity still have a "live" > StateManagerImpl > > Hi Evan, > > On Oct 30, 2007, at 12:35 PM, Evan Ireland wrote: > > > Kevin, > > > > JPA 1.0 section 3.2.3 Synchronization to the Database > > > > ... > > > > An update to the state of an entity includes both the assignment > > of a new value to a persistent property or field of the entity > > as well as the modification of a mutable value of a persistent > > property or field. > > > > If you have to call the setter method again in order for > the change to > > be detected, surely this would not be spec-compliant. > > > > Should we report this as a bug? > > Yes, please report it as a bug, and include a trivial test > case. We can then resolve it on the jira discussion. > > I wonder if there is a TCK test for this? > > One way to handle this kind of thing is to define an OpenJPA > flag like "AutoDetectArrayChanges" which has a negative > performance impact because it requires OpenJPA to compare the > before-image and after- image of all xxx[ ] field values at > flush or commit time. If the flag is false, then the only > array types that are detected are those in which the field is > replaced (even by itself). The default could be > spec-compliant (true) or non-spec-compliant. The TCK might > have to run with the flag set to slow, depending on whether > there even is a TCK test. > > Craig > > > >> -----Original Message----- > >> From: Kevin Sutter [mailto:kwsutter@gmail.com] > >> Sent: Wednesday, 31 October 2007 2:38 a.m. > >> To: dev@openjpa.apache.org > >> Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects > >> contained in a detached Entity still have a "live" StateManagerImpl > >> > >> Evan, > >> > >> On 10/28/07, Evan Ireland wrote: > >>> > >>> Since you appear to be familiar with the proxying stuff, I > >> wonder if > >>> you can say, for persistent attributes of type "byte[]" > >> which cannot > >>> be proxied, but are mutable, how does OpenJPA handle that case? > >> > >> > >> As one big blob of data... :-) If you modify the > >> individual byte array > >> contents, then you will have to re-set the array into your > >> persistence field in order for the change to be detected. > >> > >> OpenJPA also provides the ability to define a customized > type plugin > >> which might allow you to define and detect a byte[] > modification, but > >> I'm not totally familiar with this aspect to know if it would help > >> your situation or not. > >> > >> Kevin > >> > >> > >> > >> > >>> -----Original Message----- > >>>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org] > >>>> Sent: Sunday, 28 October 2007 9:22 a.m. > >>>> To: dev@openjpa.apache.org > >>>> Subject: [jira] Resolved: (OPENJPA-422) Calendar objects > >> contained > >>>> in a detached Entity still have a "live" StateManagerImpl > >>>> > >>>> > >>>> [ > >>>> https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl > >>>> assian.jira.plugin.system.issuetabpanels:all-tabpanel ] > >>>> > >>>> Kevin Sutter resolved OPENJPA-422. > >>>> ---------------------------------- > >>>> > >>>> Resolution: Fixed > >>>> > >>>> Resolved for 1.0.1 and 1.1.0 via svn revision 589207. > >>>> > >>>>> Calendar objects contained in a detached Entity still > >> have a "live" > >>>>> StateManagerImpl > >>>>> > >>>> > >> > -------------------------------------------------------------------- > >>>> -- > >>>>> -------------- > >>>>> > >>>>> Key: OPENJPA-422 > >>>>> URL: > >>>> https://issues.apache.org/jira/browse/OPENJPA-422 > >>>>> Project: OpenJPA > >>>>> Issue Type: Bug > >>>>> Components: kernel > >>>>> Affects Versions: 1.0.0 > >>>>> Reporter: Kevin Sutter > >>>>> Assignee: Kevin Sutter > >>>>> Fix For: 1.0.1, 1.1.0 > >>>>> > >>>>> > >>>>> When Entities are detached, normally the StateManagerImpl > >>>> instance associated with this Entity is replaced with a > >>>> DetachedStateManager. Not only with the Entity itself, but also > >>>> with the proxied attributes (Date, Calendar, Collection, and Map > >>>> types). But, somehow the Calendar object type was > >> forgotten in the > >>>> code for this processing. So, the Calendar proxy type > >> was left with > >>>> a "live" StateManagerImpl instance. > >>>> If the owning Broker (EntityManager) for this Entity was closed, > >>>> then the use of this "live" StateManagerImpl would end > up with an > >>>> IllegalStateException. And, even if the owning Broker > >>>> (EntityManager) was still open, this "live" > >>>> StateManagerImpl should not have been tracking the state > >> since the > >>>> enclosing Entity was detached. > >>>>> A simple one-line update to > >>>> DetachManager$DetachFieldManager.reproxy() method will > >> now process > >>>> the Calendar proxies as well as the other proxies it was already > >>>> doing. > >>>> > >>>> -- > >>>> This message is automatically generated by JIRA. > >>>> - > >>>> You can reply to this email to add a comment to the issue online. > >>>> > >>>> > >>> > >>> > >> > > > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp! > >