RE: [U2] - Determining time sequence {Unclassified}
Ross, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Ferris Sent: Friday, 1 July 2005 10:51 To: u2-users@listserver.u2ug.org Subject: RE: [U2] - Determining time sequence My only issue with using UUID's is the fact that they weren't DESIGNED for time sequencing, and you could run foul of the implementation. I just ran a quick test, fired off 4 phantoms and another screen based process to get 5,000 sequential ID's - they all finished in under a second, so 25,000+tps seems AOK ... if the item IS in contention, it will be in cache, so in practice I don't think this should be an issue. The scenario where it does become an issue is where you have transactions that run for a long (relatively) time. This means that although you have the capacity to increment the counter quickly, you can't actually do it because the update lock on the incrementing counter has to be held for the entire length of the transaction. I don't actually see how having the counter automagically maintained by the DBMS would help. For example, suppose that Transaction A starts and gets counter 654321123 Transaction B starts and gets counter 654321124 Transaction C starts and gets counter 654321125 Transaction D starts and gets counter 654321126 Now suppose that transaction B fails ... Surely transactions C D have to be rolled back because they now have the 'wrong' counter value? I don't see this as being any advance over the UV mechanism, except that it's less coding at the application level. Regards Mike Phil was originally concerned about this being a bottleneck - my (limited) testing leads me to believe this will not be the case The good news is that he now has multiple alternatives to trial. Ross Ferris Stamina Software Visage - an Evolution in Software Development The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] - Determining time sequence {Unclassified}
So you don't get the counter until you are about to complete the
transaction . timing issue would be the same with any other
technique.
Anyway, don't want to beat a dead horse - no more from me
Ross Ferris
Stamina Software
Visage - an Evolution in Software Development
-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-u2-
[EMAIL PROTECTED] On Behalf Of HENDERSON MIKE, MR
Sent: Friday, 1 July 2005 9:52 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] - Determining time sequence {Unclassified}
Ross,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Ferris
Sent: Friday, 1 July 2005 10:51
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] - Determining time sequence
My only issue with using UUID's is the fact that they weren't
DESIGNED
for time sequencing, and you could run foul of the implementation.
I just ran a quick test, fired off 4 phantoms and another screen
based
process to get 5,000 sequential ID's - they all finished in under a
second, so 25,000+tps seems AOK ... if the item IS in contention, it
will be in cache, so in practice I don't think this should be an
issue.
The scenario where it does become an issue is where you have
transactions
that run for a long (relatively) time. This means that although you
have
the capacity to increment the counter quickly, you can't actually do it
because the update lock on the incrementing counter has to be held for
the
entire length of the transaction.
I don't actually see how having the counter automagically maintained by
the DBMS would help. For example, suppose that
Transaction A starts and gets counter 654321123
Transaction B starts and gets counter 654321124
Transaction C starts and gets counter 654321125
Transaction D starts and gets counter 654321126
Now suppose that transaction B fails ...
Surely transactions C D have to be rolled back because
they
now have the 'wrong' counter value?
I don't see this as being any advance over the UV mechanism, except
that
it's less coding at the application level.
Regards
Mike
Phil was originally concerned about this being a bottleneck - my
(limited) testing leads me to believe this will not be the
case The good news is that he now has multiple alternatives to
trial.
Ross Ferris
Stamina Software
Visage - an Evolution in Software Development
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence
Force.
If you are not the intended recipient you must not use, disclose, copy
or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] - Determining time sequence {Unclassified}
What doubts, Phil? Seems, at a very quick glance, to work OK on UV10.0.15/Win2K3 If you could have more than one transaction per second, you could code GMTSecs = SYSTEM(99) MilliTime = TIME() TimeStamp = GMTSecs + MilliTime - INT(MilliTime) This would give you ~18 millisecond resolution = ~6 transactions per second (the clock on Win systems seems to increment only once per DOS Tick = 18.3ms) If you need more than 6tps, you'll need to have something more sophisticated HTH Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of phil walker Sent: Tuesday, 28 June 2005 10:38 To: u2-users@listserver.u2ug.org Subject: [U2] - Determining time sequence I need to generate a timebased sequential key which is independent of daylight savings time, so that I can consistently know in what order transactions took place even when they occur over the daylight saving time changes. I have found the following in the help system about the BASIC SYSTEM(99) function: Returns the system time in the number of seconds since midnight Greenwich Mean Time (GMT), January 1, 1970. And initially thought I could use this function, but after some testing are having doubts. Has anyone else done something similar to this? Cheers, --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] - Determining time sequence {Unclassified}
Mike,
My only doubt is having not used this before, is making sure that the
number is indeed sequential and does not get adjusted with DST. Agreed
it shouldn't but I am not sure how I would test this apart from waiting
until DST to start/finish.
I guess if it is valid, then I could use your suggestion as a key to the
records when inserting into the log and then store the DATE() and TIME()
on the record to record DST adjusted time on the record, as well as
maybe a NZST time as well. I do not need to worry about multiple time
zones.
Cheers,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of HENDERSON MIKE,
MR
Sent: Tuesday, 28 June 2005 12:16 p.m.
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] - Determining time sequence {Unclassified}
What doubts, Phil?
Seems, at a very quick glance, to work OK on UV10.0.15/Win2K3
If you could have more than one transaction per second, you could code
GMTSecs = SYSTEM(99)
MilliTime = TIME()
TimeStamp = GMTSecs + MilliTime - INT(MilliTime)
This would give you ~18 millisecond resolution = ~6 transactions per
second (the clock on Win systems seems to increment only once per DOS
Tick = 18.3ms)
If you need more than 6tps, you'll need to have something more
sophisticated
HTH
Mike
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of phil walker
Sent: Tuesday, 28 June 2005 10:38
To: u2-users@listserver.u2ug.org
Subject: [U2] - Determining time sequence
I need to generate a timebased sequential key which is independent of
daylight savings time, so that I can consistently know in what order
transactions took place even when they occur over the daylight saving
time changes.
I have found the following in the help system about the BASIC
SYSTEM(99)
function:
Returns the system time in the number of seconds
since midnight Greenwich Mean Time (GMT), January
1, 1970.
And initially thought I could use this function, but after some
testing are having doubts. Has anyone else done something similar to
this?
Cheers,
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
The information contained in this Internet Email message is intended for
the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence
Force.
If you are not the intended recipient you must not use, disclose, copy
or distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] - Determining time sequence {Unclassified}
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, 28 June 2005 12:42 To: u2-users@listserver.u2ug.org Subject: RE: [U2] - Determining time sequence [snip] This would give you ~18 millisecond resolution = ~6 transactions per second As Ken points out, 18/1000 is of the order 60, rather than 6. So, you'd be good for close to 60tps, which should be enough for most systems [snip] And how many milliseconds are you allowing in each second Mike? 1000/18 ~= 55 I knew Wellington had its charms, but time going past 10 times more quickly wasn't one that sprang to my mind first ;^) Time flies when you're having fun Obviously, Wellington must be _at_least_ ten time more fun than Sydney, Ken :-) Cheers, Ken --- The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
