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. :)
>>
>>
>