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

[Patrick Linskey <pl...@gmail.com>]

Hi,

I agree that this is a bug.

-Patrick

On Oct 30, 2007 2:00 PM, Craig L Russell <Cr...@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 <ei...@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