468,549 Members | 2,323 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,549 developers. It's quick & easy.

Timestamp issue under heavy load

We're seeing very strange behaviour with db2 under heavy load.

We're running our system in GMT and the timezone never changes for
British Summer Time.

Basically the thing we're doing is (using the udb jdbc driver):

"values current timestamp"

get that value and supply it "?" in the next insert statement :

insert into x,y,ts values (x,y,?);

Most of the time ( 99.999...%) this works fine, but what we have found
(due to debug statements etc.) that under heavy system load, the
timestamp inserted via the second statement, is actually 1 hour behind
what it should be.

Any thoughts ?

Jun 23 '06 #1
6 1680
"Chris Burnley" <ch***********@gmail.com> wrote in message
news:11*********************@y41g2000cwy.googlegro ups.com...
We're seeing very strange behaviour with db2 under heavy load.

We're running our system in GMT and the timezone never changes for
British Summer Time.

Basically the thing we're doing is (using the udb jdbc driver):

"values current timestamp"

get that value and supply it "?" in the next insert statement :

insert into x,y,ts values (x,y,?);

Most of the time ( 99.999...%) this works fine, but what we have found
(due to debug statements etc.) that under heavy system load, the
timestamp inserted via the second statement, is actually 1 hour behind
what it should be.

Any thoughts ?


Is there some reason why you don't use this:

insert into x,y,ts values (x, y, current_timestamp);
Jun 23 '06 #2
Yes there is. Basically we need to use the timestamp in another
statement later on. It is part of a key to the table we are insert into
to.
Mark A wrote:
"Chris Burnley" <ch***********@gmail.com> wrote in message
news:11*********************@y41g2000cwy.googlegro ups.com...
We're seeing very strange behaviour with db2 under heavy load.

We're running our system in GMT and the timezone never changes for
British Summer Time.

Basically the thing we're doing is (using the udb jdbc driver):

"values current timestamp"

get that value and supply it "?" in the next insert statement :

insert into x,y,ts values (x,y,?);

Most of the time ( 99.999...%) this works fine, but what we have found
(due to debug statements etc.) that under heavy system load, the
timestamp inserted via the second statement, is actually 1 hour behind
what it should be.

Any thoughts ?


Is there some reason why you don't use this:

insert into x,y,ts values (x, y, current_timestamp);


Jun 23 '06 #3
"Chris Burnley" <ch***********@gmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...
Yes there is. Basically we need to use the timestamp in another
statement later on. It is part of a key to the table we are insert into
to.


I would try this to see if it helps:

select current_timestamp from sysibm.sysdummy1;
Jun 23 '06 #4
what is the problem with :

select ts from new table (insert into table (x,y,ts) values (x,y,current
timestamp) ?

"Chris Burnley" <ch***********@gmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...
Yes there is. Basically we need to use the timestamp in another
statement later on. It is part of a key to the table we are insert into
to.
Mark A wrote:
"Chris Burnley" <ch***********@gmail.com> wrote in message
news:11*********************@y41g2000cwy.googlegro ups.com...
> We're seeing very strange behaviour with db2 under heavy load.
>
> We're running our system in GMT and the timezone never changes for
> British Summer Time.
>
> Basically the thing we're doing is (using the udb jdbc driver):
>
> "values current timestamp"
>
> get that value and supply it "?" in the next insert statement :
>
> insert into x,y,ts values (x,y,?);
>
> Most of the time ( 99.999...%) this works fine, but what we have found
> (due to debug statements etc.) that under heavy system load, the
> timestamp inserted via the second statement, is actually 1 hour behind
> what it should be.
>
> Any thoughts ?
>


Is there some reason why you don't use this:

insert into x,y,ts values (x, y, current_timestamp);

Jun 23 '06 #5
You're both missing the point. It works 99.99999% of the time,
occasionaly it doesn't work. Usually under heavy load. This to me,
smells like a race condition of some sort in the db2 driver.
Paul Peters wrote:
what is the problem with :

select ts from new table (insert into table (x,y,ts) values (x,y,current
timestamp) ?

"Chris Burnley" <ch***********@gmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...
Yes there is. Basically we need to use the timestamp in another
statement later on. It is part of a key to the table we are insert into
to.
Mark A wrote:
"Chris Burnley" <ch***********@gmail.com> wrote in message
news:11*********************@y41g2000cwy.googlegro ups.com...
> We're seeing very strange behaviour with db2 under heavy load.
>
> We're running our system in GMT and the timezone never changes for
> British Summer Time.
>
> Basically the thing we're doing is (using the udb jdbc driver):
>
> "values current timestamp"
>
> get that value and supply it "?" in the next insert statement :
>
> insert into x,y,ts values (x,y,?);
>
> Most of the time ( 99.999...%) this works fine, but what we have found
> (due to debug statements etc.) that under heavy system load, the
> timestamp inserted via the second statement, is actually 1 hour behind
> what it should be.
>
> Any thoughts ?
>

Is there some reason why you don't use this:

insert into x,y,ts values (x, y, current_timestamp);


Jun 23 '06 #6
Chris Burnley wrote:
You're both missing the point. It works 99.99999% of the time,
occasionaly it doesn't work. Usually under heavy load. This to me,
smells like a race condition of some sort in the db2 driver.

If you think it's a DB2 bug please open a PMR.
Try this alternative:
TIMESTAMP(GENERATE_UNIQUE())

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Jun 23 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Kayra Otaner | last post: by
6 posts views Thread by Robert Schuldenfrei | last post: by
1 post views Thread by Roger Twomey | last post: by
5 posts views Thread by pankaj_wolfhunter | last post: by
1 post views Thread by Frank Swarbrick | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.