Re: [Firebird-devel] Embedded superserver

[Jim S. <ja...@ne...>]

Nando Dessena wrote:

>G> I am guessing that, with an appropriate API, you may be able
>G> to offer additional server management capabilities.
>
>That's one of the things my app does. Automated database upgrade, for
>example, or alias listing, or additional security (the ability to
>assign particular aliases to particular users). In short, I want to
>augment the firebird server with features that are specific to my
>application domain, and I don't necessariliy want to do it using a
>three tier architecture (actually I currently can't).
>  
>
Let me start with some definition so we have a common vocabulary:

    * Engine -- callable code that manipulates one or more database files
    * Server -- a proxy that receives network or IPC data and makes API
      calls to an engine
    * Superserver -- a multi-threaded engine with exclusive access to
      database files
    * Classic -- an engine with shared access to database files
      coordinated with other classic engines with a lock manager.
    * Embedded -- an ambiguous reference to an engine
    * Single client server -- a server process started by inetd/xinetd
      to handle a single connection with a classic engine
    * Multi-client server -- a server that handles multiple incoming
      connections; may use either classic of superserver
    * (Vulcan engine -- an engine combining characteristics of
      superserver and classic)

The highest bandwidth path to the database is always a direct call.  
Applications that require the highest bandwidth access have a number of 
alternatives, among them:

   1. Exclusive embedded access with the existing Firebird embedded engine
   2. Shared embedded access with classic engine
   3. Adding specialized application code to database servers accessed
      by IPC or wire protocol
   4. Running database server threads in application process
   5. (Sharing database in classic mode with Vulcan multi-client server)

The system is architected so all should be possible, allowing the 
application designer to choose among performance, convenience, and 
availability tradeoffs.  The gold standard is probably #3, extending the 
existing server(s).  It's doable with the existing remote server code 
and easy with Vulcan, and the mechanisms are pretty much the same: 
create a master port object then start a server thread to listen on it.  
The current complexity is setting up the various environments that have 
nothing to do with the database service activity.

The historical goal of all database architectures is to move semantics 
closer to the disk platers.  This is the reason for high level language 
semantics (SQL vs. the earlier navigational interfaces), triggers, 
stored procedures, and plugins.  But the closer something gets to the 
disk, the more difficult it is to write, debug, and support.  For most 
applications requiring very high bandwidth database connections, outside 
the engine but inside the server is a very good compromise, and one that 
we should work to support.  I'm not suggesting (and would oppose) 
defining the internal architect of a database server process.  A clean, 
modular, class design is sufficient.

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376