Your argument makes good sense. I can see where my proposal would be
more work to implement, and still might not be faster.

Still, there are other advantages to out of process triggers. They
can be easily made to authenticate properly to the OS for doing
things outside the database. You could custom fit a sandbox that
would reduce the rights of the thread to the appropriate OS authority
(assuming they don't exceed in any way those of the database). That
would be complicated, though. Further, if we decide that such a
thread (using outside resources) is taking too long (deadlocked in a
way we can't resolve) we can just kill the process. It may or may not
be as easy to cleanly kill a VM with open handles. Finally, it seems
to me that many people using VM's at some point need to rely on some
amount of "native methods". But loading in these native methods is
tantamount to the security issues you raised before. Finally I claim
that out of process routines would add less byte bulk to the core
engine. It is after all the most significate advantage that InterBase
has over all its competition.

So maybe there is a place for both. In the web world we have in-
process, VM, and out of process API's (multiple of each, actually)
and people seem to find them all useful.

Jim

--- In IB-Architect@y..., Jim Starkey <jas@n...> wrote:
> At 07:35 AM 2/7/02 -0500, Jim Hurd wrote:
> >Why not just use hardware sandboxes? The cost of a cross process
call is
> less for most things than the cost of a software VM that can run
everything
> in-process.
> >
>
> If we were just talking about a cross process remote procedure call
> all we would need to do is handle problems of invocation,
authentication,
> dispatch, and argument marshalling. Certainly doable, at least in
> theory. But triggers and stored procedures need to call back into
> the engine to do work, and that work must be part of the same
transaction.
> So add rendevous, deadlock detection, and reverse argument
marshalling,
> and the problems starts to look complex. My personal opinion is
> undoable, but then I have little imagination.
>
> Embedding a JVM, on the other hand, is straightforward and proven.
> And I promise you that the cost in enter and leave a JVM is
significantly
> less that two context switches, particularily if the JVM
implementation
> lets you stay in the same thread.
>
> Jim Starkey