openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.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:32:35 GMT
that is correct,  the default configuration must be compatible to the 
spec regardless of whether there is a test in the TCK for a given assertion

regards
lance

Evan Ireland wrote:
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message