openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Ireland" <eirel...@sybase.com>
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 Tue, 30 Oct 2007 21:18:09 GMT
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 <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!
> 
> 


Mime
View raw message