I believe we use a large pseudo random number as the key and put the time/date stamp in a log file.
Your keys won't have the "information" in them about the sequence (although some may find that a "better" solution - let's not go there); however, a simply join/translate will get that for you. You can even do this across files.... hth Colin Alfke Calgary, Canada -----Original Message----- From: Glen B > -----Original Message----- > From: Adrian Merrall > > On Fri, Apr 25, 2008 at 10:19 PM, Marco Manyevere > wrote: > > 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. > There are other options and they all have been tested. A master service phantom responds to all initial requests with a port# to connect back on. The client reconnects from the master over to the client phantom on that port. You can have X client phantoms handling the actual processes. That provides multi-client service, but it provides it at the cost of reconnections. I utilize a file-based spooling architecture in conjunction with inet/Winetd sockets in MVWWW to avoid this reconnection scenario, but that does have performance limitations. > I did mention this was over-kill right? > It's not overkill if you need a multi-app/multi-process service that offers a single source for sequential keys. The other option is disk file locking. Any way you look at it, you have to go to one place for the key. Don't relay on O/S random numbers either. Even those are flawed at high resolution. > 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 > GlenB ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
