Subject Re: [IB-Architect] RE: Classic vs. superserver (long, very very long)
Author Jim Starkey
At 08:57 PM 10/12/2002 -0400, Claudio Valderrama C. wrote:
>> 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

The lock manager is implemented with shared memory. If a process
dies while twiddling the lock table, the world pretty much turns
to shit. The case is (or could) be detectable by other processes,
but what they could possible do about it is very much in question.

Otherwise, a process death, without regard to gore, is of almost
no consequence. Careful-write gurarentees the integrity of the
ODS: Worse case is a lost page or an unreclaimable record fragment.

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

Native code running in the database process context is bad, very bad.
The only thing worse is no-UDF's.

UDFs should run in a sandbox. [We've had this discussion before.
Look it up.]

UDF's, however, have nothing to do with classic vs. superserver;
they're a plague on both houses.

>Look in the connection handling code for the Services API, for example.

[Offensive remark about Borland engineering deleted]

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

Indeed, sir, indeed! But don't stop there! Cache the figgin'
compiled statements! Do it! Do it! Do it!

When I wrote Interbase, part of the world was Quel, part SQL, and
part Datalanguage derivative. BLR was lingua franca. 'Tis time
to note that SQL won and deserves an otherwise "unfair" advantage
with engine integration. Just abandon the BLR intermediary and
have the DSQL compiler generating runtime execution trees. It
would be smaller, faster, simpler, consume less memory, allow
sharing of compiled requests, be more maintainable, lay track,
and console old people.

And, as another demonstration of how my views have changed,
Netfrastructure is natively SQL. Not a B, an L, or an R to
be found in the entire product set.

Jim Starkey