Ann:

I renamed this thread, so that it's less confusing, and that the original thread can
continue on it's own.

On 17 Sep 2002 at 18:39, Ann W. Harrison wrote:

> At 05:12 PM 9/17/2002 -0400, Paul Schmidt wrote:
>
> >AFAICT Jim wrote the original Interbase code (please correct me if I
> >am wrong)
>
> Yes.
>
> >maybe someone could explain to those of us who are less into the
> >Interbase history, how we ended up with two variations of the same
> >theme. Namely Classic and Super Servers.
>
> The original architecture (classic) was designed for
> timesharing systems and VAX clusters - processors that
> share disk but not memory. For remote access there
> was a server on the database side that accepted incoming
> connections. Originally, there was one server for
> each connection. That began to run into process limits,
> so InterBase developed a shared server. People were
> unhappy that queries ran serially, so the server was
> changed to switch back and forth between queries.

Are process limits still an issue, I can see on a machine like a VAX, that the process
limits are fairly low, but I seem to recall that some Linux machines allow over 1000
processes, that's maybe 900 connections. I guess those processes need to share
some memory to keep from tripping over one another, and maybe that is the real
issue.

I also understand that SuperServer uses threads to switch back and forth between
queries, rather then processes. And that it's not superior to classic, just different
internally (guess it was named by the folks in marketing).

Since neither classic or super are superior to one another, they are just different, the
real issue, is what are the problems with each, and how can those problems be
resolved with the least amount of work. If the problems can be resolved using one
or the other, then we could get to the point of using a unified architecture.

Paul Schmidt, President
Tricat Technologies
paul@...
www.tricattechnologies.com