Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!phobos!forrest
From: forrest@phobos.sybase.com (Jon Forrest)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <7037@sybase.sybase.com>
Date: 12 Nov 89 04:56:58 GMT
References: <2184@kodak.UUCP> <6895@sybase.sybase.com> <122@tacitus.tfic.bc.ca>
Sender: news@sybase.sybase.com
Reply-To: forrest@sybase.com
Organization: Sybase, Inc.
Lines: 91

I said :

One of the strong points of the Sybase architecture is that we
require only one operating system process per Server. Internal
to this process is our own multitasking kernel which handles
many of the facilities that other systems rely on the operating
system to provide.

Chris Hermansen writes in response :

   I apologize in advance if this sounds like a flame; it's not meant to be :-)
   
   So (I believe) you are claiming that Sybase is `better' at implementing
   the elements of the `multitasking kernel' you hint at above?  Better than
   what?  If I may guess at what the original poster was hinting at, s/he is
   of the opinion that your software is more efficient than others because it
   uses fewer processes; your answer appears to be that you use your own
   rather than the operating system's.  In order to substantiate your claim for
   improved efficiency, you might want to present some more solid info as to
   how *your* kernel is better than the O/S.

I retort :

  Although in my original posting I never said that Sybase is better at
  implementing the elements of a multitasking kernel than a native O.S., I'll
  accept your challenge and give you a couple of examples of how
  certain features of our multitasking kernel are better than one
  O.S., VMS. Note that I don't hold this against the VMS. One
  operating system can't be everything to all people.

  The first example is process creating. Process creation on VMS
  is expensive because a process requires a lot of context and
  resources. People that have ported certain Unix program to VMS
  soon learn about this. While I have no real problem with this
  when using VMS interactively, such behavior was unacceptable
  in our server. Our database processes are much simpler than VMS processes.
  Thus, why should we carry the weight of a VMS process on our
  shoulders when we don't need most of what it has to offer?

  The second example has to do with locks. The VMS lock manager is
  a strange and wonderful thing that was designed to provide lock
  manager services within a cluster. Providing such services is again
  much more complicated than providing locking within one process.
  Also, the model of locking provided by the VMS lock manager is
  different than what our server requires.
  In this case by using a single VMS process we were able to provide
  all the services our server requires without the overhead and
  complexity of the VMS lock manager. Indeed I believe that
  Oracle's problems on a Vaxcluster are due to VMS lock manager
  overhead and complexity. (An Oracle person told me this yesterday
  on the plane home from DECUS.)

  I could probably go on but I hope you see my point. Our server,
  as well as servers from our competition, don't need all the services
  provided by a native O.S.. As the O.S. becomes more complicated,
  (VMS vs. Unix) this becomes more obvious.

I also wrote :

  Another benefit of this approach is that our
  Server needs no special privileges to run. The operating system
  sees our Server as just another non-privileged user process.
  Therefore, we can't crash the machine running our Server.

Chris Hermansen continues :

  Maybe I'm being a little dense here; I don't have a strong feeling as to
  why any other architecture needs `special privileges' to run.
  
and in response to my claim that we can't crash the machine running
our Server :
  
  Haw.  I've heard THIS before.

I reply :
  Dense might not be the right word. In any case, I don't know if
  our competition requires special privileges. This wasn't the point
  I was trying to make. Any program of any kind that doesn't requires
  special privileges shouldn't be able to crash the machine on which
  it is running unless the machine is very badly tuned or else the
  O.S. isn't intended for production environments. I know that I feel
  good knowing that in the only case I know of that a machine running
  Sybase has crashed it has been because of a bug in VMS.

----
Anything you read here is my opinion and in no way represents Sybase, Inc.

Jon Forrest WB6EDM
forrest@sybase.com
{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest
415-596-3422