Thank you all for all the responses.
I was hoping that somewhere within the operating system's scheduling
mechanism there is something like a timeslice serial number which could be
read with some system function. No 2 processes could ever return the same
timeslice serial number within a day for example. My unique id would then be
formed as follows:
<snip>
BASEKEY = DATE():"*":time slice serial number
IF BASEKEY EQ PREVBASEKEY THEN
SEQ.NUM += 1
ELSE
PREVBASEKEY = BASEKEY
SEQ.NUM = 1
END
UNIQUE.KEY = BASEKEY:"*":SEQ.NUM
</snip>
This way there would be no need for extra IOs and no bottlenecks on a
syncronisation key.
--- On Fri, 25/4/08, Glen B <[EMAIL PROTECTED]> wrote:
From: Glen B <[EMAIL PROTECTED]>
Subject: RE: [U2] Guaranteed unique sequential keys
To: [email protected]
Date: Friday, 25 April, 2008, 5:30 AM
You'll need a central key generator to manage high
resolution sortable
sequential keys. You can use whatever connection medium is feasible and let
a single process/phantom generate the keys in numerical order. The problem
with using a key generator like this is that you could easily produce a
bottleneck. On the other hand, the benefit of doing it this way is that the
generator can be a single phantom. It can keep track of the last used key in
memory and can pregenerate keys for near-future or parallel usage. If the
connection medium you choose allows for multiple requests at a time, then
your management code must be able to manage and pregenerate keys for each
"thread" concurrently. A wide solution could be a socket service that
serves
unique keys to clients. I use base-16 for a lot of sequential keys so that I
have many unique iterations per key length. I always use them as direct
pointers and I never sort them, though. Hex sortability from
LIST/SORT/SELECT could be questionable.
Glen
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Marco Manyevere
> Sent: Thursday, April 24, 2008 5:55 AM
> To: [email protected]
> Subject: [U2] Guaranteed unique sequential keys
>
>
> What is the most reliable way to generate unique sequential keys without
> having to resort to a record on disk updated through readu/write? The
keys
> don't have to be contiguous but only be sortable in the order in
> which they
> were generated by several phantom processes running concurrently. I'm
> currently approximating this using a concatenation of date and time with
> millisecondsB but I'm worried about the possibility of two
> phantoms generating
> exactly the same key.
> B
> Although no collision has been detected so far, I
> have added an extra check where after generating the key I first test if
a
> record with that key exists. If so IB increment and append aB
> serial number
> and repeat the test until aB unique key is found. ItB seems to be
> working well
> but I still think there is a better way to do this.
> B
> Thanks for any help.
> B
> Marco.
>
>
> __________________________________________________________
> Sent
> from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
> -------
> u2-users mailing list
> [email protected]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit
http://listserver.u2ug.org/
_________________________________________________________________
Yahoo! For Good. Give and get cool things for free, reduce waste and help
our planet. Plus find hidden Yahoo! treasure
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
