roller-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dick Davies (JIRA)" <>
Subject [jira] Created: (ROL-1760) Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
Date Thu, 20 Nov 2008 16:24:19 GMT
Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)

                 Key: ROL-1760
             Project: Roller
          Issue Type: Bug
          Components: Database Access & Data Model
    Affects Versions: 4.0
         Environment: Solaris 10, Oracle 10gR2, Roller 4.0.1
            Reporter: Dick Davies
            Assignee: Roller Unassigned

Rollers JPA config seems to assume that CURRENT_TIMESTAMP is low precision 
(i.e. hundredths of a second).

Specifically, I'm not sure the ORM config in TaskLock.orm.xml is correct.

On databases that have microsecond resolution (Oracle, PostgreSQL, etc.) the 
JPAThreadManagerImpl.registerLease() method quickly gets into a state where the 

NamedUpdate never suceeds,

and so tasks never run.
(There was a similar issue with DB2 that resulted in us dumping that , so it's not all bad
:) )

I turned on JPA debugging and on Oracle 10, we see 

DEBUG 2008-11-20 15:30:00,064 CommonsLogFactory$LogAdapter:trace - Executing query: [UPDATE
TaskLock t SET t.clientId=?1, t.timeAquired= CURRENT_TIMESTAMP, t.timeLeased= ?2, t.lastRun=
?3 WHERE AND t.timeAquired=?5 AND ?6 < CURRENT_TIMESTAMP] with parameters: {3=Thu
Aug 07 16:07:00 BST 2008, 2=PingQueueTask, 1=2008-08-07 16:37:00.07, 6=2008-11-20 15:30:00.0,
5=30, 4=devel-roller01}
DEBUG 2008-11-20 15:30:00,065 CommonsLogFactory$LogAdapter:trace - <t 28169327, conn 12589755>
executing prepstmnt 11980159 UPDATE roller_tasklock t0 SET timeleased = ?, client = ?, lastrun
= ?, timeacquired = CURRENT_TIMESTAMP WHERE ( = ? AND t0.timeacquired = ? AND ? <
CURRENT_TIMESTAMP) [params=(int) 30, (String) devel-roller01, (Timestamp) 2008-11-20 15:30:00.0,
(String) PingQueueTask, (Timestamp) 2008-08-07 16:07:00.07, (Timestamp) 2008-08-07 16:37:00.07]
TIMEACQUIRED at that time was '07-AUG-08 PM', and since Oracle checks down
to the microsecond
when comparing timestamps, this means the WHERE clause never matches and nothing updates.

The WHERE clause seems overly picky in any case -  
the schema creation scripts declare the column to be unique, so 'WHERE = ?' is enough
to find the right row, surely?

Another fix is to declare the timestamp columns as timestamp(2) in the Oracle 
(+DB2 + PostgreSQL ? ) creation scripts. We're trying that now to see if it helps.

Do you want a bug filed?


This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message