Multithreading and PreparedStatement

Question

I am debugging a problem with the interaction between Hibernate and our JDBC driver.
Hibernate uses a PreparedStatement to insert values into the database. When it inserts a Timestamp value into the database, it sets the value into the Timestamp object, calls setTimestamp, and then it uses the same Timestamp object in other threads, setting it to different values, before it calls execute on the PreparedStatement.
My question is, is it valid for an application to assume that the JDBC driver has made a copy of the Timestamp value when it calls setTimestamp, or should it hold off on reusing the Timestamp value until after it has called execute?
To me it seems that the driver should be able to defer all processing of the PreparedStatement parameters until execute(), because the application could call clearParameters, in which case any work done by the JDBC driver would be wasted. This is not so obvious for Timestamp parameters, but what about stream parameters? Clearly the driver is not going to read the stream until execute.

Answer 1

I'm not talking about POJO. Think just straight JDBC, inside the guts of Hibernate.
Here is what Hibernate is doing:
Timestamp ts = new Timestamp();
// this one timestamp object is used by multiple threads
<now we have a thread that does this>
PreparedStatement pstmt = connection.prepareStatement("some sql");
ts.setTime(something);
pstmt.setTimestamp(n, ts);
<then, another thread does this:>
PreparedStatement pstmt1 = connection.prepareStatement("some sql");
ts.setTime(something else);
pstmt1.setTimestamp(n1, ts);
<meanwhile, the original thread is doing this>
pstmt.execute();
The JDBC driver only keeps a reference to the timestamp when Hibernate calls setTimestamp(). By the time Hibernate calls execute(), another thread has already picked up this timestamp object and reused it, so it doesn't contain the same value that it did when it called setTimestamp().
It's really horrible when the second thread calls setTime() when the first thread is in the execute() call, in the middle of reading its value to send it to the database, because the first thread reads an inconsistent value from the timstamp object and sends it to the database, which barfs because the inconsistent value ends up being something like Feb. 30. I can get this nightmare to happen pretty regularly on an SMP machine.
My question is: is Hibernate doing something bad by reusing the Timestamp object before calling execute(), or is the JDBC driver at fault for not keeping a copy of the Timestamp object at setTimestamp() time? I have read the JDBC spec over and over again and I can't see an answer to this question.