Track: Databases
Date: Thursday, August 4th, 2005
Time: 11:35am - 12:20pm
Location: D136
Not all database applications consist of a single database running on a dedicated machine, accessed by remote clients. Some require the throughput of an application linked directly to the database handling code. Others are self-contained and should not affect any system-wide settings. The Firebird database engine has three configurations: a shared server, an embedded server, and a library of access routines. The API is the same, so you can offer different models for ‘personal’ and ‘corporate’ versions of your application.
The traditional model for databases is a single server running on a dedicated system. In Firebird, this model is SuperServer. The server process listens for connection requests, maps transactions to threads, and maintains shared caches of metadata and database pages. In Firebird 2, you can configure a system to support several instances of the SuperServer to manage individual databases, or groups of databases, separately.
The SuperServer code that handles database operations can be built as a library and linked directly to applications. This model is “Classic” Firebird. A shared memory lock table coordinates the activity of separate applications.
Data management is also important for personal applications – applications designed to run on PC’s – not dedicated database servers. For these applications, Firebird has embedded mode. The server and all its configuration information is bound to an application that has exclusive access to the databases it uses.
Firebird’s API is consistent across all models – this talk explains how to choose the model – or models – that fit your application.
Download presentation file
..::firebird::..
No comments:
Post a Comment