| Subject | Re: [IB-Architect] RE: Classic vs. superserver (long, very very long) |
|---|---|
| Author | Jim Starkey |
| Post date | 2002-10-13T14:46:54Z |
At 08:57 PM 10/12/2002 -0400, Claudio Valderrama C. wrote:
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.
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.
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
>>The lock manager is implemented with shared memory. If a process
>> 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?
>
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 aNative code running in the database process context is bad, very bad.
>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.
>
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.
>[Offensive remark about Borland engineering deleted]
>Look in the connection handling code for the Services API, for example.
>;-)
>
>Indeed, sir, indeed! But don't stop there! Cache the figgin'
>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.
>
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