db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kalén <mka...@apache.org>
Subject Oracle, timestamp locking and nanoseconds
Date Wed, 23 Feb 2005 20:00:07 GMT
Greetings,
  a somewhat length summary of tonight's detective work on OJB. :)

Originally the story started when I was debugging Oracle test-case 
failures in OJB and homed in on ClassDescriptor and the use of 
java.sql.Timestamp.

In the "locked-by-timestamp" locking tests, the code in ClassDescriptor 
would set a "new java.sql.Timestamp()" as object value before writing 
the lock out to DB. When the value was read back from Oracle the 
.getNanos() always resulted 0 and would cause locking exceptions (since 
nanos in the object written out was not always, almost never in fact, 
set to 0).

I misinterpreted "setNanos", didn't check the JDBC doco properly, and 
submitted a patch that Armin applied with setNanos(0) in the 
ClassDescriptor-code (which will in fact truncate nanos, micros and 
millis *doh*).

This did solve the Oracle failures in the test-cases, but later on a 
user realized that this created problems on other platforms. Armin then 
accepted a patch from this user that did not truncate the nanos 
completely, but folded it down to microsecond precision.

This still failed with Oracle though, but today for the first time I 
really checked the DDL and saw that Torque was generating a DATE-column 
for LOCKED_BY_TIMESTAMP.TIMESTAMP_ - argh! How silly.

A bit of googling reveals that Oracle in pre-9 versions does not have 
TIMESTAMP, only DATE - with second precision. That is why my old patch 
worked on Oracle but stuffed up locking precision to such a low 
granularity to cause problems on other platforms.


Summary: there was nothing wrong in ClassDescriptor in the first place, 
just the Torque-generated DDL for the test cases.

I have rolled out both patches in order to raise lock precision back to 
nanosecond for all platforms.


The locking-test will only work for Oracle9i or higher and only if we 
get Torque to generate correct DDL. I interpret this Torque issue:
http://issues.apache.org/scarab/issues/id/TRQS263
as that they are working on it. It might actually already be possible to 
switch between Oracle v<=8 or 9+ in Toqrue 3.1.1 - I will look into this 
later.

For now, I think I will submit a change to the timestamp locking 
testcases that will treat Oracle* platforms as a "known issue" and skip 
on -DOJB.skip.issues=true, using ojbSkipKnownIssueProblem. At least in 
1.0-branch.

Regards,
  Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message