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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org > 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 > 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/ _________________________________________________________________ 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/