You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@roller.apache.org by "Dick Davies (JIRA)" <ji...@apache.org> on 2008/11/20 17:24:19 UTC
[jira] Created: (ROL-1760) Scheduled tasks do not run on Oracle (or
other DBs with high precision timestamps)
Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
----------------------------------------------------------------------------------
Key: ROL-1760
URL: https://issues.apache.org/roller/browse/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
"TaskLock.updateClient&Timeacquired&Timeleased&LastRunByName&Timeacquired" 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 t.name=?4 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 (t0.name = ? 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 04.07.00.069896 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 roller_tasklock.name column to be unique, so 'WHERE to.name = ?' 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.
[jira] Commented: (ROL-1760) Scheduled tasks do not run on Oracle
(or other DBs with high precision timestamps)
Posted by "Ceri Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/roller/browse/ROL-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14455#action_14455 ]
Ceri Davies commented on ROL-1760:
----------------------------------
That SQL clause is presumably there to allow for multiple cluster nodes to run the same task concurrently.
I don't see any implementation of that anywhere, so it can probably just go away as we agree is the simplest fix, but it would be good to check that it doesn't override design somewhere.
> Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
> ----------------------------------------------------------------------------------
>
> Key: ROL-1760
> URL: https://issues.apache.org/roller/browse/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
> "TaskLock.updateClient&Timeacquired&Timeleased&LastRunByName&Timeacquired" 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 t.name=?4 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 (t0.name = ? 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 04.07.00.069896 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 roller_tasklock.name column to be unique, so 'WHERE to.name = ?' 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.
[jira] Commented: (ROL-1760) Scheduled tasks do not run on Oracle
(or other DBs with high precision timestamps)
Posted by "Ron Peterson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/roller/browse/ROL-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14466#action_14466 ]
Ron Peterson commented on ROL-1760:
-----------------------------------
Just confirming that using the original query, but reducing the timestamp resolution in the database fixes the problem in PostgreSQL also.
alter table roller_tasklock alter timeacquired type timestamp(2) with time zone;
alter table roller_tasklock alter lastrun type timestamp(2) with time zone;
> Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
> ----------------------------------------------------------------------------------
>
> Key: ROL-1760
> URL: https://issues.apache.org/roller/browse/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
> "TaskLock.updateClient&Timeacquired&Timeleased&LastRunByName&Timeacquired" 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 t.name=?4 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 (t0.name = ? 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 04.07.00.069896 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 roller_tasklock.name column to be unique, so 'WHERE to.name = ?' 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.
[jira] Commented: (ROL-1760) Scheduled tasks do not run on Oracle
(or other DBs with high precision timestamps)
Posted by "Ron Peterson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/roller/browse/ROL-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14454#action_14454 ]
Ron Peterson commented on ROL-1760:
-----------------------------------
I fixed this on my PostgreSQL/Roller 4.0.1 installation by editing org/apache/roller/weblogger/pojos/TaskLock.orm.xml, changing
UPDATE TaskLock t
SET t.clientId=?1,
t.timeAquired = CURRENT_TIMESTAMP,
t.timeLeased= ?2,
t.lastRun= ?3
WHERE t.name=?4 AND
t.timeAquired=?5 AND
?6 < CURRENT_TIMESTAMP
to
UPDATE TaskLock t
SET t.clientId=?1,
t.timeAquired = CURRENT_TIMESTAMP,
t.timeLeased= ?2,
t.lastRun= ?3
WHERE t.name=?4</query>
I'm not sure this is a better solution than altering the database timestamp resolution, though.
> Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
> ----------------------------------------------------------------------------------
>
> Key: ROL-1760
> URL: https://issues.apache.org/roller/browse/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
> "TaskLock.updateClient&Timeacquired&Timeleased&LastRunByName&Timeacquired" 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 t.name=?4 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 (t0.name = ? 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 04.07.00.069896 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 roller_tasklock.name column to be unique, so 'WHERE to.name = ?' 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.
[jira] Commented: (ROL-1760) Scheduled tasks do not run on Oracle
(or other DBs with high precision timestamps)
Posted by "Ceri Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/roller/browse/ROL-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14449#action_14449 ]
Ceri Davies commented on ROL-1760:
----------------------------------
As the DBA on this issue, I thought I'd mention that altering the timestamp columns to hundredths of second via timestamp(2) has resolved this issue for us.
> Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
> ----------------------------------------------------------------------------------
>
> Key: ROL-1760
> URL: https://issues.apache.org/roller/browse/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
> "TaskLock.updateClient&Timeacquired&Timeleased&LastRunByName&Timeacquired" 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 t.name=?4 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 (t0.name = ? 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 04.07.00.069896 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 roller_tasklock.name column to be unique, so 'WHERE to.name = ?' 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.
[jira] Commented: (ROL-1760) Scheduled tasks do not run on Oracle
(or other DBs with high precision timestamps)
Posted by "Anil Gangolli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/roller/browse/ROL-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14461#action_14461 ]
Anil Gangolli commented on ROL-1760:
------------------------------------
Ceri is correct. The whole point of this functionality is to allow multiple callers on one or more hosts to attempt to run the same task (only one should succeed). The WHERE clause is there to prevent a caller from claiming the lease while it is still held by another one. The issue is the equality comparison and granularity of the stored value.
> Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
> ----------------------------------------------------------------------------------
>
> Key: ROL-1760
> URL: https://issues.apache.org/roller/browse/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
> "TaskLock.updateClient&Timeacquired&Timeleased&LastRunByName&Timeacquired" 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 t.name=?4 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 (t0.name = ? 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 04.07.00.069896 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 roller_tasklock.name column to be unique, so 'WHERE to.name = ?' 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.
[jira] Commented: (ROL-1760) Scheduled tasks do not run on Oracle
(or other DBs with high precision timestamps)
Posted by "Ceri Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/roller/browse/ROL-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14452#action_14452 ]
Ceri Davies commented on ROL-1760:
----------------------------------
Linking to ROL-1657 which appears to have the same root cause.
> Scheduled tasks do not run on Oracle (or other DBs with high precision timestamps)
> ----------------------------------------------------------------------------------
>
> Key: ROL-1760
> URL: https://issues.apache.org/roller/browse/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
> "TaskLock.updateClient&Timeacquired&Timeleased&LastRunByName&Timeacquired" 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 t.name=?4 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 (t0.name = ? 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 04.07.00.069896 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 roller_tasklock.name column to be unique, so 'WHERE to.name = ?' 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.