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