At 12:25 PM 9/18/2002 -0400, Paul Schmidt wrote:

> >
> > >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 ...
>
>Are process limits still an issue,

No, but neither clusters of machines that share disk but not memory.
Nor is lack processing power a problem.

>I guess those processes need to share
>some memory to keep from tripping over one another, and maybe that is the
>real
>issue.

Not particularly. The problem with the classic architecture is
not that it shares too much, but that it shares too little. Each
connection keeps its own metadata cache and its own page cache.

>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).

Given the state of computing today, I'd say that a shared server
is vastly superior to a multi-process access method. The multi-
process was a good solution to a problem that no longer exists.

>the
>real issue, is what are the problems with each, and how can those problems be
>resolved with the least amount of work.

We should be prepared for some 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
>
>
>To unsubscribe from this group, send an email to:
>IB-Architect-unsubscribe@onelist.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/