persistence@glassfish.java.net

Re: Object (Timestamp) entity fields not persisted when changed internally

From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Wed, 12 Nov 2008 10:05:50 -0800

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