> --- In IB-Architect@y..., "Ann W. Harrison" <aharrison@i...> wrote:
> Here's my take on the issue of classic vs. superserver.
>
> A catastrophic error in a single connection doesn't
> affect other connections, while a server crash brings down
> all connections.

I'm not sure the environment is so clean even in classic after one
connection dies ungracefully. What happens with the lock manager, for
example?

> The server shouldn't crash. Ever.
> Earlier versions of InterBase did not isolate UDF's, and
> allowed user code to crash the server. That's been fixed
> for nearly four years.

Sorry, do you consider the change a fix? What they did was: to detect a
problem in the UDF, then the engine prints a message saying the UDF did an
illegal operation, so the server will be shutdown... and the engine
terminates itself by brute force.

> Now, it's up to us to find and
> fix the places in the server where bad inputs can cause
> crashes.

Look in the connection handling code for the Services API, for example.
;-)

> Yes, we could add shared page and metadata caching to classic,
> but that's redoing work that's already been done in superserver,
> and it still requires fine granularity locking if it's going
> to run well on an SMP system. What we'd be doing, if we tried
> to build from the classic base, is redoing all the work that's
> already gone into superserver.

We can also unify the metadata cache used by the core engine and the DSQL
layer, instead of having to maintain two distinct but somewhat equivalent
set of structures.

C.