You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Martin Kalén <mk...@apache.org> on 2005/02/23 21:00:07 UTC
Oracle, timestamp locking and nanoseconds
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
Re: Oracle, timestamp locking and nanoseconds
Posted by Thomas Dudziak <to...@gmail.com>.
OJB 1.1 will use ddlutils (once that is finally established) instead
of Torque, so that won't be an issue anyway.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Oracle, timestamp locking and nanoseconds
Posted by Martin Kalén <mk...@apache.org>.
Armin Waibel wrote:
> I never used torque, but I found in torque jar under
> torque-3.0.2.jar\sql\base\oracle the file dp.props. Seems that this file
> is responsible for java/sql mapping. Maybe a modified class could solve
> the problem.
Bingo, that's the one. Hm... ugly to have a patched prop file for Torque
3.0.2. Maybe better to wait for Torque 3.1.x in OJB 1.1 instead and just
set these tests as known failures 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
Re: Oracle, timestamp locking and nanoseconds
Posted by Armin Waibel <ar...@apache.org>.
Hi Martin,
your mail sounds like a detective novel detective novel ;-)
Martin Kalén wrote:
> Martin Kalén wrote:
>
>> 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_
>
>
> Now reproduced ~10 times:
> testTimestampLock with DDL as auto-generated by Torque (ie column
> _TIMESTAMP as Oracle datatype DATE): FAIL
>
> After the following SQL...
> alter table LOCKED_BY_TIMESTAMP modify (TIMESTAMP_ TIMESTAMP);
> ...the test is 100% OK.
>
> Anyone know if we can get the old Torque to produce TIMESTAMP for Oracle
> 9 or higher?
>
I never used torque, but I found in torque jar under
torque-3.0.2.jar\sql\base\oracle the file dp.props. Seems that this file
is responsible for java/sql mapping. Maybe a modified class could solve
the problem.
regards,
Armin
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Oracle, timestamp locking and nanoseconds
Posted by Martin Kalén <mk...@apache.org>.
Martin Kalén wrote:
> 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_
Now reproduced ~10 times:
testTimestampLock with DDL as auto-generated by Torque (ie column
_TIMESTAMP as Oracle datatype DATE): FAIL
After the following SQL...
alter table LOCKED_BY_TIMESTAMP modify (TIMESTAMP_ TIMESTAMP);
...the test is 100% OK.
Anyone know if we can get the old Torque to produce TIMESTAMP for Oracle
9 or higher?
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org