Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!mephisto!mcnc!rti!xyzzy!aquila.Berkeley.EDU!harrism From: harrism@aquila.Berkeley.EDU (Mike Harris) Newsgroups: comp.databases Subject: Re: Client/Server processes and implementations Keywords: Client Server Processes Message-ID: <879@xyzzy.UUCP> Date: 1 Dec 89 17:20:16 GMT References: <7237@sybase.sybase.com> <7139@sybase.sybase.com> <2184@kodak.UUCP> <6895@sybase.sybase.com> <122@tacitus.tfic.bc.ca> <7037@sybase.sybase.com> <125@tacitus.tfic.bc.ca> <684@xyzzy.UUCP> Sender: usenet@xyzzy.UUCP Reply-To: harrism@aquila.Berkeley.EDU (Mike Harris) Distribution: usa Lines: 80 [forrest writes:] > Although you are welcome to talk theoretically, until you can buy our > (or anyone else's) MP product it isn't fair to talk about what such > a product can or can't do. I have been careful to avoid discussing our > MP product partially because it isn't right to talk about unreleased > products on comp.databases. You can buy our DG/SQL database manager. You can buy our TPMS transaction manager. You can buy our DG/DBMS database manager. You can buy the Sperry/Unisys data managers & transaction managers...Most of these products have been available for more than 5 years. The Server Manager that I am working on will be shipping early next year (you can order it now) with DG/ICOBOL & DG/Object-Office. Soon thereafter with DG/ISAM. (These latter three on UNIX). I haven't been discussing academic research which hasn't a base in reality. > > Please elaborate. How does our current (Release 4.0) product lack > tunability and scalability? If it lacks MP support (or concurrently schedulable threads) then it lacks support for a significant aspect of application performance tuning. I didn't mean to imply that it didn't have any support for tuning. Sorry. > [ good stuff about portable code, etc] I believe that there is a middle line that is somewhere between your Sybase product &, for example, our very propriatary DG/SQL. Utilization of commonly available features such as multi processors is a requirement. Use of commonly available I/O primitives is another (async I/O, etc). For example, I don't know of any os that doesn't have primitives that aren't close enough to allow the creation of a small sync subsystem. The subsystem must be ported to different OSs, but it isn't difficult if the developer only uses basic functions such as P() & V(). Your product is more portable & runs on a wide variety of smaller platforms. Our (DG/SQL) isn't as portable, but it is faster & supports large platforms (one customer has 750 concurrent users). Different ends of the extremes! We are working to make ours more portable & you are working to make yours take advantage of larger (read mp, etc) platforms. effic > > Again, having multiple servers accessing the same database requires > all sorts of additional concurrency control using O.S. services. > I don't argue that in theory being able to do this is a bad idea. It works in practice. Earlier comments describe such systems. > ....under many O.S.'s, the penalty in doing ... this can eat up much of the > gain. When you combine this with all the platform specific code ... > If one is careful to use "commonly" available functionality & insulate the remainder of the code from it with a standard interface, then there is a win. To me, common at the moment includes primitive semaphores P(), V(), basic shared memory, possibly message queues (an easy to write subsystem using shm & sems), and some I/O operations. Things that don't count are OS threads and/or tasks, fancy I/O, etc. Standard RPC packages are coming out so I'd add those to the list of "common" soon. BTW, it is MUCH easier to put in support for MP (or distribution, or whatever..) from the beginning than it is to retrofit something to it. The "MUCH" depends upon whether or not MP was a consideration (a planned future) when the product was designed. Your MP work shouldn't be too difficult as you basically had a multi process architecture with your internal threads. A significant head start, indeed! > I'm ... much more interested in seeing a "server" run on a 6 CPU MP machine > than on 6 separate machines. So am I. The split is usually best based upon the application requirements - frequently accessed vs never acessed databases, etc. This is where the big consulting $$$ come in! The beauty is that there isn't any absolutes - only guidlines. Therefore, there is always work to do & $$ to earn. > > Jon Forrest WB6EDM regards, Mike Harris - KM4UL harrism@dg-rtp.dg.com Data General Corporation {world}!mcnc!rti!dg-rtp!harrism Research Triangle Park, NC Brought to you by Super Global Mega Corp .com