Firebird Documentation IndexFirebird 2.5 Release Notes → Changes in the Firebird Engine
Firebird Home Firebird Home Prev: New in Firebird 2.5Firebird Documentation IndexUp: Firebird 2.5 Release NotesNext: Thread-safe Client Library

Changes in the Firebird Engine

Table of Contents

New Threading Architecture
Thread-safe Client Library
Improvements

The primary objective of this release was to refactor Firebird's threading architecture to take advantage of the symmetric multiprocessing (SMP) capabilities of multiprocessor hardware. This has a noticeable effect on the scaleability of Superserver when multiple databases are being accessed simultaneously but its major effect is the emergence of the architectural “Superclassic” model that will underpin the fine-grained multi-threading under development for Firebird 3.

New Threading Architecture

Dmitry Yemanov

Vladyslav Khorsun

Alex Peshkov

also -

Nickolay Samofatov

Roman Simakov

For Superserver, the new architecture will be most obvious in two ways:

  1. In a multiple database environment, Superserver threads for each database are allotted evenly to available processors.

    Note

    The default CpuAffinity setting still binds SuperServer to a single processor only. In order to take advantage of this improvement when working with multiple databases, this setting should be changed in firebird.conf.

  2. A slight improvement in scaling should be apparent for single database usage on SMP hardware

It is with Classic that the effects are most evident:

  1. Classic Server can now be multi-threaded. The one worker thread per process model remains but now it is possible to use additional threads for parallel tasks such as asynchronous shutdown, sweep, inter-process communications with the lock manager and more.

  2. On POSIX, services in Classic also run in threads now, rather than in forked processes as previously.

    Note

    For Windows Classic, services became threadable in v.2.1.

  3. The embedded libraries—libfbembed.so on POSIX and fbembed.dll on Windows—are now multi-thread-capable and thread-safe, so they can be used in multi-threaded applications.

  4. Testing suggests that the performance of Classic in this version will be be significantly faster than previous Classic versions.

Superclassic

This multi-threaded mode for Classic has been dubbed “Superclassic” for its capability to handle multiple worker threads—dedicated or pooled—inside a single server process. It shares all the usual Classic features, with a few differences:

  • Safe, full shutdown of the server engine is possible on any platform

  • Under some TPC conditions, it can outperform Classic—by about 15-20%

  • It uses fewer kernel resources (although not less memory)

  • When a Superclassic process crashes, it takes all its connections with it

  • Recognised limitations in the Services API for the Classic server, such as the inability to retrieve the list of attachments/active users, do not apply to SuperClassic.

  • On POSIX, Superclassic does not require [x]inetd.

Embedded Server Notes

  • The embedded server in the Windows library, fbembed.dll, now uses Superclassic, not Superserver as previously, thus unifying its model with that of local connection to Superclassic on POSIX. The database file-lock that previously restricted connections to a single application space is replaced by a global lock table that allows simultaneous access to the same database from different embedded server modules. This facilitates concurrent debugging of applications and use of native utility tools like gbak, gstat and so on.

  • A single attachment handle can now be shared by simultaneous threads. (Tracker reference CORE-2498, A. dos Santos Fernandes).

Usage Notes

Windows

On Windows, the same fb_inet_server.exe binary delivers either the Classic or the Superclassic working modes, according to switch settings. Classic is the default mode.

To use the Superclassic mode as a service, add the -m[ulti-threaded] switch to the instsvc.execommand line, as follows:

instsvc install -multithreaded
            

When intending to run Superclassic as an application, use

fb_inet_server -a -m
            
New Binary for POSIX

On POSIX, the new binary fb_smp_server is supplied for the Superclassic model. It contains the network listener, meaning it works similarly to fbserver with regard to attachment requests and does not require [x]inetd.

The multi-threaded engine used by fb_smp_server is the libfbembed.so library, in accordance with OSRI requirements. The Classic packages also include fbguard (the Guardian) which, in a Superclassic installation, starts fb_smp_server, rather than fbserver as it does when the Superserver model is installed with Guardian.

Important

Do not try to use fbguard when running the traditional Classic server.

Prev: New in Firebird 2.5Firebird Documentation IndexUp: Firebird 2.5 Release NotesNext: Thread-safe Client Library
Firebird Documentation IndexFirebird 2.5 Release Notes → Changes in the Firebird Engine