The story of linter database starts back in 1980 when a group of developers working in a government-owned company started to develop a database system named DBMS BARS for a RANFOS operating system.
Later in the 1990 same group set a private company named RELEX which is acronym for "RELational EXpert Systems" and this is when Linter database has arrived.
Strict 2 phase locking. Thus, every DML operation causing an exclusive lock to be put on the record that is being changed at the moment.
When a select statement reaches the tuple that has been updated but not yet committed, it gets stalled until the lock is down.
Whenever a transaction updates many tuples on the same table, the whole table gets an exclusive lock in order to reduce resource overhead while managing multiple row-level locks
Deadlocks are being detected on the fly by the means of an internal deadlock manager
Indexes are implemented in form of a B*-tree (which is a subtype of a B-tree with only difference that it requires each internal node to be at least 2/3 full) type of indexes implemented: simple index, composite index, functional index, Ad-hoc index - an index that database creates on the fly while optimizing a query. Gets deleted once the query is executed, and text index for the text search
Each table of Linter database is being stored in a set of datafiles. There are separate files for table data, index data, and unstructured data. Files are being named using following convention XXX.YNN Where XXX: is the internal table id Y: 0 - for table data, 1 - for index data, 2 - for unstructured data (BLOB) NN: numeric order
For example: 159.12 - is the second file storing index data for a table which internal id is 159
The Linter's internal procedural language has no other name rather than "procedural language" and PL/SQL-like scripting language