We do a lot of end-dating. When we end-date something, we set that property on a persistent object to the appservers date (via new Date()) and then commit it. Our queries use sysdate or current_date. The problem is that there is a bit of time drift between our appservers and db server.

One solution is to keep the server's clocks in sync, but then we'd depend on an outside variable to maintain application integrity..not prefrable. The most logical approach is to use the same method at getting the current time. What’s the best approach to do this?

Instead of using sysdate or current_date in our queries, we could pass in the current date from the appserver. The problem is that in a clustered environment, the date could vary.

So what I’d really like to do is to set the property to the value of sysdate or current_date in the db. Is there any way to do this directly with hibernate?

Or any other strategies to solve the problem?

Thanks.
-peter


Hibernate version:2.1.7

Name and version of the database you are using:Oracle9i

Sure, why not just grab a database connection from the session factory (sf.openSession().connection()) and query for the current database date?

You mean execute a little natice sql and then manually set the end date value?

I was hoping for a bit more portable and automated solution.

-peter

Why is this not portable?

Exactly how is Hibernate supposed to know when a given row should be end-dated?

Because I would assume that you're suggesting execute a little sql with the connection, perhaps something like "select sysdate from dual".
I'm not sure but, I'm thinking that's not going to work so well on db's other then oracle.

By "a little more automated", i was hoping not to have to execute any sql manually.



I don't expect it to know anything about when to end-date something; that's an application level semantic.
I was hoping that there was a way to have hibernate set a field to the current date, on-demand rather then all the time like <timestamp>.
I've only used end-dating as an example of once case where this kind of feature would solve.