Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of plinskey@gmail.com designates
 64.233.162.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=htIe1qWrMsE+iBhPrWVhk6w8pQY2hgEStrlVv6PJvMoeVIPBc+OGrwTWqpZ/nidAAKizXrRII/1YTZas11OXZST1Wfit57Yx5u+dfYUzutmrsCF7ri+OVwmzIGP3jgJAyP+j1bCnDhyIfzdTW7DfniFo9gAoDsW1kCHQb3ZsGPw=
Message-ID: <7262f25e0711011008u33518a5bg69b5ec35e5289a6c@mail.gmail.com>
Date: Thu, 1 Nov 2007 10:08:43 -0700
From: "Patrick Linskey" <plinskey@gmail.com>
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
In-Reply-To: <BDB7B863-46B8-4003-8EB2-3AC11B80B469@SUN.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <10024094.1193514710553.JavaMail.jira@brutus>
	 <7056240.1193516510596.JavaMail.jira@brutus>
	 <003501c8199d$dc20b4f0$0500a8c0@kokako>
	 <89c0c52c0710300637s12481018h281482af59968672@mail.gmail.com>
	 <001e01c81b2c$0aa18e50$0500a8c0@kokako>
	 <BDB7B863-46B8-4003-8EB2-3AC11B80B469@SUN.com>

Hi,

I agree that this is a bug.

-Patrick

On Oct 30, 2007 2:00 PM, Craig L Russell <Craig.Russell@sun.com> wrote:
> 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 <eireland@sybase.com> 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!
>
>


-- 
Patrick Linskey
202 669 5907