Hello, I'm using hibernate 2.1.4 with MSSQL 2000. I'm encountering a problem with unchanged objects being flushed back to the database. The hibernate log is showing an unchanged timestamp column as being dirty.

I patched class TimestampType and added some logging to equals(). What I am seeing is the timestamps appear to be the same, but looking carefully, x.getTime() is returning milliseconds, while y.getTime() is not. For instance:

(TimestampType.java:70) - TimestampType.equals(x=2004-06-06 17:23:08.92, y=2004-06-06 17:23:08.92) equals=false
(TimestampType.java:77) - TimestampType.equals(xTime=1086560588920 yTime=1086560588000)
(TimestampType.java:78) - TimestampType.equals(xts=true yts=true)
(TimestampType.java:85) - TimestampType.equals(xNanos=920000000 yNanos=920000000)
(TimestampType.java:87) - TimestampType.equals(xTime=1086560589840 yTime=1086560588920)
(AbstractEntityPersister.java:274) - com.foo.ClientTransactionClass.createStamp is dirty
(SessionImpl.java:2529) - Updating entity: [com.foo.ClientTransactionClass#CTT000000369001]

What I don't understand is that at line 70, the values for both x.toString() and y.toString() both display 92 milliseconds. However, yTime [y.getTime()] is missing the milliseconds. Line 70 also shows that x.equals(y) returns false. Line 85 shows 92 milliseconds for both x and y.

The updated TimestampType.equals() method is below.

Thanks for your help,
Dave

Yeah think this is a bug with java.sql.Timestamp class. If one of the objects is a java.sql.Timestamp and the other is a java.util.Date then you get equality problems.

See this thread.

http://forum.hibernate.org/viewtopic.php?t=927602

Clearly, your timestamp is not, in fact, unchanged. Hibernate is perfect, your code is the problem ;-)

My createStamp property of the object in question is a java.sql.Timestamp. My hibernate mapping file doesn't explicitly set the type, but hibernate appears to be mapping it to TimestampType as expected.

Gavin, of course hibernate is perfect! Unfortunately, I am having a bit of trouble understanding this less than perfect behavior.

How can both x.toString() and y.toString() return the same "2004-06-06 17:23:08.92", but x.getTime() returns 1086560588920, and y.getTime() returns 1086560588000?

Thanks,
Dave

The long value is measured in milliseconds which are not significant digits when expressed in the string representation of the date.

You are forgetting about Timestamp.getNanos(), which sometimes sucks up some of the millisecond value!

Gavin,

Timestamp.getNanos() is returning 920000000 (92 milliseconds) for both x and y.

The issue appears to be that x.getTime() is reflecting the 92 milliseconds (the final three digits in 1086560588920), but y.getTime() is not (1086560588000).

Sorry if I am being slow here, but why would getNanos() reflect 92 milliseconds, while getTime() does not for the same Timestamp?

Thanks,
Dave

A Timestamp sometimes holds some of the milliseconds stuff in the nanos part. You have to add them together to get the "real" milliseconds.

Gavin,

I see. Thanks. So:



Results in:



The TimestampType.equals() method appears to be expecting this behavior. The problem is that for the 'old' value, stored by hibernate in the session, x.getTime() *does* return the 92 milliseconds. So the code:



Is actually calculating the wrong value, don't you think? I notice that you keep stating that Timestamp 'sometimes' pulls the milliseconds component of the time out of getTime(). What is this dependent on?

Thanks,
Dave

Sorry to reply to my own post, but I think this is a bug in TimestampType. Depending upon the JVM version (and some other unknown factor), java.sql.Timestamp.getTime() may or may not return the milliseconds component of the time.

The TimestampType.equals() method assumes that the milliseconds component has been stripped, and adds the milliseconds to getTime() using getNanos() before doing the equals comparison.

TimestampType.equals() also happens to work when Timestamp.getTime() does return the milliseconds component for both x and y. The xTime and yTime variables are actually calculated to the incorrect value (the milliseconds component of the timestamp are included twice), but this doesn't affect the outcome of the comparison.

For me, for a reason I have yet to determine, x.getTime() [hibernate session stored value] returns the milliseconds component of the timestamp, but y.getTime() [my object] strips it. This is why the equals fails. This can be easily corrected with the following code:



This will mask off the milliseconds component prior to adding it back via getNanos().

Can anyone who is familiar with the Timestamp.getTime() issues and this component please comment on this?

Thanks for your help,
Dave

I am very happy with the current implementation, which always increments the millis part with any millisecond value contained in the nanos part.

It does not just naively compare millis parts.

Look at this, your timestamps actually have different values:



This is after the adjustment that accounts for nanoseconds parts!


certainly not Hibernate's fault.

Please note that IBM JDK 1.3.1 has a bug where




I hope you are not using new Timestamp().

Gavin,

Please look again at the inputs to equals(). The x input object instance is from my jdbc driver and is in my mapped object.

x.toString()=2004-06-06 17:23:08.92
x.getTime()=1086560588920
x.getNanos()=920000000

The y input is a copy that hibernate stores in the session and is used in the dirty check.

y.toString()=2004-06-06 17:23:08.92 (same as x)
y.getTime() = 1086560588000 (not same as x -> 2004-06-06 17:23:08.0)
y.getNanos()=920000000

As you stated, the final xTime you calculate after the nanosecond adjustment is 1086560589840. Please note that new Timestamp(1086560589840L) = '2004-06-06 17:23:09.84'. Clearly that is incorrect.

Now the issue may be actually 'y'. When hibernate takes my timestamp 1086560588920 and stores in in the session, the resulting timestamp.getTime() returns 1086560588000.

Thanks for working with me on this,
Dave

Gavin,

I am using Sun's Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03). Yes it does have the new Timestamp(x).getTime()!=x defect. Hibernate's Environment.jvmHasTimestampBug() method returns true.

Dave