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