Since we're talking OOB (out of box) why not try the user semaphore locking that is built into the system. Check the BASIC LOCK and UNLOCK , and LIST.LOCKS in tcl. Your process cant write until it can lock. It writes, then unlocks. and so on. j
On 4/25/08, Marco Manyevere <[EMAIL PROTECTED]> wrote: > 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/ > -- john ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
