Has anyone considered submitting the transactions to said phantom, and have one process control the writes?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen B Sent: Friday, April 25, 2008 10:53 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Guaranteed unique sequential keys > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Adrian Merrall > Sent: Friday, April 25, 2008 8:07 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Guaranteed unique sequential keys > > > On Fri, Apr 25, 2008 at 10:19 PM, Marco Manyevere <[EMAIL PROTECTED]> > 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/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
