A problem with introducing Java into the engine is that Java
is designed for fine granuality threading and the current
InterBase (FireBird? How about just JRD?) engine has extremely
coarse threading.

JRD was written before threading was available on any microprocessor
operating system and long before multi-microprocessors architectures
existing, and eons before operating systems could dispatch threads
on different processors. The first JRD support for threading was
version 3 for VMS (I wrote the thread manager) and Apollo (there's
a long story there); Sun had shipped a version of SunOS, but even
their example didn't work. The goal of the original threading was
to support a multi-client server. The implementation relies on
a single controlled resource -- the entire engine -- which is
locked exclusiving with a THREAD_ENTER macro and released with
THREAD_EXIT. This was state of the art (and appropriate) for
1990, but that was 40 Internet years ago.

To support internal Java, multi-processors, and higher throughput,
this has got to change. Rather than a single engine lock, each
independent data structure should be interlocked. Although a
simple Java-like monitor would suffice, a Shared/Exclusive scheme
would give significantly better throughput at a minor cost in
complexity.

The problem with fine grained synchronization is the interaction
with exception handling. When something goes wrong, it is
absolutely essential that any resources locked be released. The
current JRD exception handling is cobbled with setjump/longjump.
Changed the granularity of synchonization necessary involves an
overhaul of the exception mechanism. The overhaul would involve
either a) the addition of a great deal of fussy code wherever any
resource is locked to ensure that the resource is released following
an exception, or b) finding a automatic mechanism.

A very elegant solution is available in C++: Each controlled
object contains a synchronization object which is controlled
through a stack local object with a destructor to release the
lock on function exit or exception unwind. A C implementation
is possible, but without object destructors, it would involve
a great deal of hard to test, hard to maintain, fussy code,
with great temptation for a developer to think "ah, I know
nothing I am calling can ever throw an exception, so why
don't I just skip the cleanup."

If there is ambition to move FireBird forward, I think a conversion
to C++ is not only desirable, but essential. Or to put the
question another way, I think the effort to convert to C++
will return a major short term profit and a promise of long
term dividends ("dividends" -- an amusing but archaic financial
concept).

Jim Starkey