ORACLE TIMESTAMP DataType support in Toplink ?

Question

Currently we have an application that need to create timestamps with precision up to thousands of a second.
Do you know of any other customer that have similar requirements and how they solve this problem ?
We try changing the SQL DDL to change datatype from DATE to TIMESTAMP(3) which can support a timestamp of 1/1000 seconds precision.
We find that if our Oracle column is defined as Oracle DATE, the last 3 digit will be drop and cause us some duplicate key exception for records that
Get inserted within 1 second because the timestamp is part of the primary key.
ts '2004-03-12 17:13:27.792'
So we change the ORACLE column from DATE to TIMESTAMP(3)
What we find is that Toplink produce this exception
Exception [TOPLINK-3001] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.ConversionException
Exception Description: The object [oracle.sql.TIMESTAMP@321b5e39], of class [class oracle.sql.TIMESTAMP], could not be converted to [class java.util.Date].
at oracle.toplink.exceptions.ConversionException.couldNotBeConverted(ConversionException.java:35)
at oracle.toplink.internal.helper.ConversionManager.convertObjectToUtilDate(ConversionManager.java:679)
at oracle.toplink.internal.helper.ConversionManager.convertObject(ConversionManager.java:97)
at oracle.toplink.internal.databaseaccess.DatabasePlatform.convertObject(DatabasePlatform.java:55
Than we try to change our java code and modify the java instance variable type from java.util.Date to java.sql.Timestamp
And we get the following error
Exception [TOPLINK-3001] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.ConversionException
Exception Description: The object [oracle.sql.TIMESTAMP@731de027], of class [class oracle.sql.TIMESTAMP], could not be converted to [class java.sql.Timestamp].
at org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java:650)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1011)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1564)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:335)
We cannot seems to find in toplink mapping workbench how to specify timestamp
========================================================================================================
The TIMESTAMP Datatype
The new TIMESTAMP datatype is almost identical to DATE and differs in only one way:
TIMESTAMPs can represent fractional seconds.
The granularity of a TIMESTAMP value can be as little as a billionth of a second, whereas
DATE variables can only resolve time to the second.
When you declare a TIMESTAMP variable, you can optionally specify the precision that you wish to use for fractional seconds. The default precision is to the millisecond (six decimal digits); the maximum precision is to the billionth of a second (nine decimal digits).
===========================================================================================================
-----Original Message-----
From: Cheung, Ka-Kit
Sent: Friday, March 12, 2004 6:20 PM
To: Burr, Tim; Julian, Robert; Matthiesen, Sean
Cc: Tsounis, George; Del Rosso, Peter; Cham, Mei
Subject: Problem identified : AddressDetail duplicate key problem
If we look at the exact of the insert statement.
We see that the last address detail insert have key of
Address ID = '5a052407-dac6-42ad-bbbf-29edc94488c1', and
TransactionStartDate = {ts '2004-03-12 17:13:27.792'},
While in the database, we look like we have an entry of
Address ID = '5a052407-dac6-42ad-bbbf-29edc94488c1', and
TransactionStartDate = {ts '2004-03-12 17:13:27.229'},
If my memory served me right, while
{ts '2004-03-12 17:13:27.792'}, is different than {ts '2004-03-12 17:13:27.229'},
because are Java timestamps that have precison up to MicroSeconds, therefore 229 is different than 792.
However, when this timestamp is saved to Oracle, I believe (have to check with Mei) that oracle only takes
Up to '2004-03-12 17:13:27’ and discard the 229 or 792 because that is the maximum precision of timestamp for oracle.
So we have the second insert have the same '2004-03-12 17:13:27’ after stripping off the 792 and we have a same record with the same same '2004-03-12 17:13:27’ in the database and
Therefore causing duplicate key exception.
That is why this is happen only once in a while when 2 rapid fire inserts happen in less than 1 second of each other.
The solution actually is in the ESS code itselfs.
The current ESS code will send addDependentToClient multiple times, one for each dependent added
On the screen.
The right way is to add all the dependent on the screen all at once.
To have “course grain” method like addDependentsToClient, and have a collection or array of dependents as input parameter.
This way we are not causing the participant to create history of themselves multiple times within a very short period of time. It save disk space, conform to a single UOW per submit and that is what I proposed
To solve this problem from the root cause is by enhancing the method to save multiple dependents in one shot rather than a loop of multiple calls.
KK
and
INSERT INTO PTTCBSI.ADDRESS_DETAIL
(LINE_3_AD, ADR_TRAN_UNTIL_DT, MODIFY_DT, CITY_NM, POSTAL_CD, VER_ID, POSTAL_EXT_CD, LINE_2_AD, ADR_TRAN_START_DT, CREATE_DT, AUTHOR_ID, ADDRESS_ID, LINE_1_AD, COUNTY_NM, LINE_4_AD, COUNTRY_ID, STATE_ID)
VALUES ('Block 5, Apt. 6', {ts '9999-12-31 00:00:00.0'},
{ts '2004-03-12 17:13:26.385'},
'Oakwood', '61043', 1, '1234', 'Mailstop 820',
{ts '2004-03-12 17:13:26.385'},
{ts '2004-03-12 16:50:12.0'}, 'dataLoad',
'5a052407-dac6-42ad-bbbf-29edc94488c1',
'IBM Corp.', NULL, '140 Main Street', 'US', 'NJ')
UnitOfWork(1238222885)--Connection(2102560837)--
UPDATE PTTCBSI.ADDRESS_DETAIL
SET ADR_TRAN_UNTIL_DT = {ts '2004-03-12 17:13:26.385'}, VER_ID = 2 WHERE
(((ADDRESS_ID = '5a052407-dac6-42ad-bbbf-29edc94488c1') AND
(ADR_TRAN_START_DT = {ts '2004-03-12 16:52:29.0'})) AND (VER_ID = 1))
UPDATE PTTCBSI.ADDRESS_DETAIL SET
ADR_TRAN_UNTIL_DT = {ts '2004-03-12 17:13:27.229'}, VER_ID = 2
WHERE (((ADDRESS_ID = '5a052407-dac6-42ad-bbbf-29edc94488c1') AND (ADR_TRAN_START_DT = {ts '2004-03-12 17:13:26.0'})) AND (VER_ID = 1))
UnitOfWork(102762535)--Connection(2102560837)--
INSERT INTO PTTCBSI.ADDRESS_DETAIL
(LINE_3_AD, ADR_TRAN_UNTIL_DT, MODIFY_DT, CITY_NM, POSTAL_CD, VER_ID, POSTAL_EXT_CD, LINE_2_AD, ADR_TRAN_START_DT, CREATE_DT, AUTHOR_ID, ADDRESS_ID, LINE_1_AD, COUNTY_NM, LINE_4_AD, COUNTRY_ID, STATE_ID) VALUES
('Block 5, Apt. 6', {ts '9999-12-31 00:00:00.0'}, {ts '2004-03-12 17:13:27.229'}, 'Oakwood', '61043', 1, '1234', 'Mailstop 820',
{ts '2004-03-12 17:13:27.229'},
{ts '2004-03-12 16:50:12.0'}, 'dataLoad',
'5a052407-dac6-42ad-bbbf-29edc94488c1',
'IBM Corp.', NULL, '140 Main Street', 'US', 'NJ')
INSERT INTO PTTCBSI.ADDRESS_DETAIL
(LINE_3_AD,
ADR_TRAN_UNTIL_DT,
MODIFY_DT,
CITY_NM, POSTAL_CD, VER_ID, POSTAL_EXT_CD, LINE_2_AD,
ADR_TRAN_START_DT,
CREATE_DT,
AUTHOR_ID,
ADDRESS_ID,
LINE_1_AD, COUNTY_NM, LINE_4_AD, COUNTRY_ID, STATE_ID) VALUES
('Block 5, Apt. 6', {ts '9999-12-31 00:00:00.0'},
{ts '2004-03-12 17:13:27.792'},
'Oakwood', '61043', 1, '1234',
'Mailstop 820',
{ts '2004-03-12 17:13:27.792'},
{ts '2004-03-12 16:50:12.0'},
'dataLoad',
'5a052407-dac6-42ad-bbbf-29edc94488c1',
'IBM Corp.', NULL, '140 Main Street', 'US', 'NJ')
ClientSession(790235177)--Connection(2102560837)--rollback transaction
ORA-00001: unique constraint (PTTCBSI.PK_ADDRESS_DETAIL) violated

Answer 1

KK,
We are back-porting the support for oracle.sql.TIMESTAMP to 9.0.4 in an upcoming patch-set. It is possible to enhance TopLink using a customer conversion manager or database platform to add this support if required in the short term.
Doug