Do you expect the spec to change in requirements for support of mutable types?
thanks,
-marina
Gordon Yorke wrote:
> The problem here is that this bug was fixed for the Java Util types and
> not for java.sql types.
> Also the patch that was put in Glassfish was not merged back into
> TopLink and therefor will not be in V3 (EclipseLink)
> --Gordon
>
> Marina Vatkina wrote:
>
>> Gordon,
>>
>> Is it a regression?
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1637 had been
>> fixed a long time ago (as mentioned there, spec says in 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.
>>
>> thanks,
>> -marina
>>
>> Gordon Yorke wrote:
>>
>>> This has nothing to do with caching. The Timestamp is treated as
>>> immutable by the change detection code so without changing the
>>> timestamp instance no change is detected. In V3 (EclipseLink) there
>>> is a @Mutable annotation to cover the case where your code needs to
>>> change the internal values.
>>> --Gordon
>>>
>>> Eric Amy wrote:
>>>
>>>> The previous posts that I can find regarding this always recommend
>>>> turning off caching. This would be a functional work-around if the
>>>> issue is caused by what I initially thought of when I encountered
>>>> the behavior. I'll now describe the behavior and my guess at the
>>>> bug. Feel free to tell me I'm over-simplifying it.
>>>>
>>>> Using Glassfish v2ur2:
>>>> Create an @Entity that contains a column field of type
>>>> java.sql.Timestamp. Persist the entity; then change the timestamp's
>>>> value by calling setTime(long). After merging and subsequent
>>>> flushing, the new value is not persisted to the database. The
>>>> easiest work-around is to construct a new Timestamp rather than
>>>> using the setter. This makes the new value persist on the first flush.
>>>>
>>>> What I imagine could be happening is this: at some point in the
>>>> caching algorithms, it would be assumed that the entity fields are
>>>> primitives (or at least passed by value). So the scenario, where
>>>> (timestamp_old == timestamp_new) is true but
>>>> (timestamp_old.equals(timestamp_new)) is false, is over-looked.
>>>>
>>>> I realize that what I described is a very simple mistake, and I
>>>> already have a work-around, but I'd still like to know what's going
>>>> on 'under the hood' to cause this if I'm wrong. :)
>>>
>>>
>>>
>>