File server

The simplest server for ODABA applications is the file server. The file server mode uses the file services from the operating system to provide multiple application access to an ODABA database. The file server is simply to administrate, but it it requires fast connection since each i/o request is sent to the server. Moreover, file servers do not generate events and thus, other applications sharing the same server have to ask for changes.

File server access is a simple way of establishing a multiple client environment, i.e. making a database available for more than one client or thread running in parallel. The situation does not differ much whether running more than one application locally or whether sharing the database with other users in the local network or the internet.

File server mode causes significant amount of traffic and should be used in environments only, where at least 100 MBit/second are guaranteed. Practically, the database might be located in the internet, but because of low transfer rate, applications may become very slow.

The advantage of a file server is that there are nearly no administration resources required. Just store the database file(s) on accessible drive and refer to the data source in the configuration or ini-file (see example below). The data source might be set also directly within the application or database can be opened in file access mode explicitly (Database::open()).

When data transfer is to slow, it is better to setup an ODABA server.

In order to improve performance, one may enable the root base cache by defining a [CACHE] section in the ini-file or by calling ShareRootBase() in the application program before opening may database. Within the [CACHE] section one may (but need not) define additional cache options. When activating the root base cache, section, instance descriptors (and instances) are cached. When root base cache is enabled, resource locks are managed via the root base cache (between threads) and via file locks (between processes).

Event triggering mechanisms in file server mode are limited. Since a file server (SAMBA) cannot sent database events to other clients, only update events can be triggered by comparing instance or collection modification counts, i.e. when accessing an instance or collection (but not immediately, when being changed).