4D
4D is a relational DBMS that is integrated with an IDE and a proprietary programming language. It allows users to create custom graphical interfaces to work with their database, which can then be run on Windows or Mac OS systems to edit a locally stored database file. 4D can also run as a server so that multiple clients can manage a single database. The latest version of 4D includes "4D for iOS Preview" which creates a customizable iOS app for viewing database contents.
Foreign Keys
4D supports One-to-One, Many-to-One, and Many-to-Many relations between tables. Relations are classified as either automatic or manual. Automatic relations cause foreign records to be loaded with records that reference them, while manual relations do not. Automatic relations should avoid cyclic references.
Indexes
B+Tree Inverted Index (Full Text)
Indices can use a B+Tree or clustered B+Tree. 4D supports composite indices (indices on pairs of values). It also supports keyword indices (indices mapping individual words to records containing them).
Isolation Levels
Transactions lock records they modify or create, preventing other transactions from interfering with them. Unrepeatable reads may occur since transactions do not lock records they read. Table entries can be added while a transaction is running, creating invalid aggregation results (phantom problem). Transactions store all modifications in a temporary buffer, so uncommitted data can't affect other transactions.
Isolations levels for 4D transactions are not mentioned in the product documentation, but the behavior is consistent with the Read Committed isolation level.
Checkpoints
Every modification to the data file since the last backup is recorded in the associated log file ("*.journal"). If the database file is corrupted, 4D will restore the most recent backup and replay the changes in the log. When a new backup is created, the log file is cleared. Backups can be triggered manually or on a schedule. The database cannot be edited while a backup is running.
Concurrency Control
4D requires users to explicitly lock/unlock records and avoid deadlocks. For every user/process, each table in the database is given a read-only or read/write status. If a table is in the read-only state for a given user, all existing records loaded from the table are considered locked and cannot be modified. Any user can append new records to a table, even if it is read-only. If a table is in the read/write state, records will load as unlocked for the first user to load them. To modify a record that is already locked, a user can repeatedly load the record until it unlocks. A user unloads a record to make it available again to other users/processes.
A user can change a table from read-only to read/write or back at any time, but this only affects future load requests made by that user. If a read/write command is executed on a locked record, the command will either be ignored, display an error, or skip the record (if the command targets multiple records). Skipped records are added to the LockedSet of the requesting process to alert it of the error.
Queries can be grouped into transactions to ensure that changes occur atomically, but there is no deadlock prevention/detection. While a transaction is running, changes are saved into a temporary buffer and any modified records are locked.
