DbTimestamp uses local time for @Version field on Oracle 11g

Description

When you using DbTimestamp to use the database to seed the timestamp (for the @Version oplock field), this delegates to getCurrentTimestampSelectString().

On Oracle 10g this invokes "select systimestamp from dual". This returns the server's local time. This causes problems when crossing the cutoff between (for example) British Summer Time and UTC. The standard SQL function, current_timestamp (returned by getCurrentTimestampSQLFunctionName should be used instead. This always returns UTC time.

public String getCurrentTimestampSelectString() {
return "select systimestamp from dual"; // suggest changing to
// return "select " + getCurrentTimestampSQLFunctionName() + " from dual";
}

public String getCurrentTimestampSQLFunctionName() {
// the standard SQL function name is current_timestamp...
return "current_timestamp";
}

NB getCurrentTimestampSelectString() is only referenced from the DbTimestamp class

Attachments

1
  • 10 Sep 2010, 11:07 PM

Activity

Show:

Brett Meyer July 8, 2014 at 3:11 PM

Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!

Brett Meyer April 7, 2014 at 5:43 PM

In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.

If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.

Thank you!

Rejected
Created September 10, 2010 at 11:07 PM
Updated July 8, 2014 at 3:11 PM
Resolved July 8, 2014 at 3:11 PM

Flag notifications