Robert martin wrote:

>
> We choose to use the Super Server version of FB based on the following
> information at
>
> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_ss_vs_classic
>

IBPhoenix has a lot of archival material, and this is one example. The
article reflects the best thinking about the future of InterBase seven
years ago. Since then, low-end computer architectures have changed and
the change affect the trade-offs that were made in creating SuperServer.

Borland continues to deprecate and abandon Classic ports. When Firebird
started, we had a long wrangle about maintaining two architectures, and
in the end, decided to do so. In Version 1.5, Firebird introduced
Classic for Windows - a platform that had never had a classic version.

The strongest arguments for classic are

1) it performs well on machines with separate processors that share
memory and disk - SMP being the prime example.

2) applications that run on the same system as the database access it
through a subroutine call rather than a process switch - vastly faster.

The strongest arguments against classic are

1) security - tons of security issues, ranging from the ability of an
application to write over the database access code to the requirement
that each local client process have write access to the database.

2) lack of shared cache, meaning that "hot" pages - pages that are
modified often by many connections, cause a serious I/O load.

The argument against having both is that the code base is heavily
conditionalized to allow both to be built, to the point of interfering
with its maintainability. Vulcan addresses that issue as well as SMP.


Regards,


Ann