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
The Linter's internal procedural language has no other name rather than "procedural language" and PL/SQL-like scripting language
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 names using following naming convention XXX.YNN 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 index file of a table which id is 159
DBMS BARS, DBMS INTEREAL
C, C#, C++, Delphi, Java, Perl, PHP, Ruby, SQL, Tcl
Linux, QNX, Windows