On Fri, Apr 25, 2008 at 10:19 PM, Marco Manyevere <[EMAIL PROTECTED]> wrote:
> Thank you all for all the responses. > Marco, One last thought looking at your OP for a non-disk IO locking function, I don't see how you can avoid disk IO unless there is some kind of of in-memory locking process. There may be a kernel option you could use but I'm not a c programmer so can't say. In bash I have seen a lot of the classic test/touch but this can lead to race conditions and a symlink is a more robust solution. However, I'm not sure running a ln -s command at the OS level is going to be faster than a readu (and I can't see from your posts if you are on a *nix platform and even have that option). So... in the best traditions of using a pile-driver to crack a nut you could roll your own . Of the top of my head, a locking service would be a U2 subroutine listening on a particular network port that is started/stopped along with the DB. Your client routines would use the socket functions to connect. The nice thing is you get the duplicate connection handling for free. U2 socket listeners are not multi-threaded so the first client in gets the socket. As long as you hold it for 1 clock tick before closing and have the other clients on a time-out longer than 1 clock-tick, you should get your unique keys. I did mention this was over-kill right? Although the code itself is pretty simple and, in my experience on Unidata, the U2 sockets routines work very well, I would spend some time benchmarking to make sure this kind of effort is worthwhile. Assuming you have some spare server capacity, if the phantoms are using a lock file on a frequent basis, the file will likely be in cache anyway. HTH but probably not. Adrian > > 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/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
