At 02:03 PM 10/10/02 -0700, John Bellardo wrote:

>
>I'm not familiar with the Oracle model, but I too am thinking about a
>multi-process multi-threaded model. The basic idea is the "server"
>consists of one or more processes. These processes in turn consist of
>one or (more probably) more threads. Depending on the actual site
>configuration, installations might range from single process for all
>attachments (much like SS is now) to a single process per database to a
>single process for each attachment (like CS now). Most importantly the
>engine code needs to be the same in all cases (not the SS ifdef's we
>have now). Through the use of exclusive DB locks we should be able to
>add performance optimizations for the SS-style installation while
>retaining the multi-process functionality.
>

Best of luck. I don't think it will ever work. But you might
surprise me. But I don't think so. And if it did work, I don't
think you'd be happy with the results.

Multi-process/ multi-thread combines the worst of super server
with the worst of classic -- it has the lock and interprocess
overhead of classic with the threading complexity of superserver.

Perhaps there has been discussion of the goals and aspirations
of the project on other lists. Is to make a high performance,
highly scalable database server or a mimimalist person database
engine? Should be be considered primarily as an embedded
engine, or is the a general purpose beast?

Jim Starkey