The Firebird server comes in several “models” that provide a variety of scaling options, ranging from the single-user, stand-alone desktop to the server farm.
Figure depicts a flexible system, where multiple Firebird servers are running on different operating and filesystem platforms. There is a mix of workstations, each running remote clients appropriate to its local platform. There are gateways to other networks. The Windows server here happens to be serving the day-to-day data processing of the business and is commanding a lot of disk capacity. It is possible for the Windows clients to be conversing with the Windows server using the Named Pipes protocol—commonly called NetBEUI—although it should be avoided in favor of TCP/IP, if possible.
The Linux server may be serving firewalls, gateways, ancillary databases, and other client/server systems, including company e-mail, Internet, and file services, such as NFS and Samba.
Two-tier Firebird client/server topology
Heterogeneous database-serving networks are a common environment for Firebird. In small, single-server networks where an on -site administrator may not be part of the permanent staff, the trend is moving away from running the database server on a single, high-specification, multi-purpose Windows host, toward low-cost, dedicated Linux machines, well-supplied with RAM and fast storage. Maintenance is low, making it realistic to outsource most of the administrative functions. Systems like this have capacity for growth without major upheaval.
The Single-User Model
All Firebird servers can accept local clients. The connection protocols and options vary according to the server model you choose. Single-user installations fall into two categories:
In the stand-alone client/server model, the localized client attaches to the running server using a local protocol. The server can listen for connections from remote clients while a local client is attached. Figure illustrates the options.
The first example shows the local connect model. Up to and including Firebird 1.5, the IPSERVER subsystem simulates a network connection within the same block of interprocess communication space. Beyond v.1.5, IPSERVER is deprecated in favor of a local protocol using the faster, more robust, native XNET subsystem. A functionally equivalent local connect is supported for Classic server on POSIX.
In the other two examples, on Windows, Linux, or any other supported platform, the TCP/IP local loopback protocol is used with the Superserver. It is a regular TCP/IP attachment to the special IP address 127.0.0.1, which most TCP/IP subsystems install by default as the named host localhost. On Linux, the v.1.5 Classic server can be used in this mode, provided the client library libfbclient.so is used.
Embedded servers are supported on both Windows and Linux/UNIX platforms, although the implementation models are different. The embedded server library on Windows, which runs an exclusive Superserver process, is called fbembed.dll. On Linux/UNIX, it is the standard mode for a local connection to the Classic server. The library libfbembed.so starts a single Classic server process (fb _inet _server or ib_inet_server) and attaches directly to a database. It is not exclusive—remote clients can connect concurrently, using fbclient.so, another libfbembed.so, or fbclient.dll.
Embedded servers are discussed in more detail in the next chapter.
Firebird Servers in DTP Environments
A detailed discussion of distributed transaction processing (DTP) environments is beyond the scope of this guide. However, suffice it to say that Firebird Superserver or Classic server sits well in a variety of DTP scenarios.
The Open Group defined the X/Open standard for DTP, envisioning three software components in a DTP system. The XA specification defines the interface between two of them: the transaction manager and the resource manager (RM). The system has one RM module for each server, and each RM is required to register with the transaction manager.
Figure illustrates how a Firebird server could be slotted into an XA-compliant DTP environment. The database application server module provides a bridge between high-level user applications and the RM, encapsulating the XA connection. The RM performs a client like role to negotiate with the database server for access to data storage.
The encapsulation of the XA connection enables the application developer to build and execute SQL statements against the RM. Transaction demarcation—which requires two-phase commit capability on the part of all servers—is moderated by the global transaction processing monitor (TPM). Cross-database transactions under the management of a transaction manager are made through a two-phase commit process. In the first phase, transactions are prepared to commit; in the second, the transaction is either fully committed or rolled back.The TPM will alert the calling module when a transaction does not complete for some reason.
Firebird in distributed transaction processing environments
The TPM coordinates distributed transactions in multiple database systems so that, for example, one transaction can involve one or more processes and update one or more databases. It keeps account of which RMs are available and involved in transactions.
The framework supports multiple databases per server and multiple servers, which need not all be Firebird. Up to and including v.1.5, Firebird does not support spanning a single database across multiple servers or serving a database that is not controlled by its host machine.
Transaction Server Frameworks
Microsoft Transaction Server (MTS) with COM+ is one such scenario. MTS/COM+ provides a process-pooling environment that encompasses the deployment and management of business logic components, including auditing control, security, and performance monitoring. One of its most significant features is declarative transaction management. Transactions initiated by MTS/COM+ are controlled by the Microsoft Distributed Transactions Coordinator (DTC), an XA resource manager. The native Firebird interface requires an ODBC or OLE DB provider that supports both Firebird’s two- phase commit capability and the MTS/COM+ call context.
Firebird is successfully deployed in MTS and IBM Citrix frameworks. The protocol is TCP/IP with attachments connecting to network IP addresses in all cases.
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.