Concurrency Control

Two-Phase Locking (Deadlock Detection)

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

Data Model

Relational

Foreign Keys

Supported

Indexes

B+Tree

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

Isolation Levels

Read Committed

Logging

Physical Logging

Query Interface

SQL Stored Procedures

Storage Architecture

Disk-oriented

Storage Model

N-ary Storage Model (Row/Record)

Storage Organization

Sorted Files

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

Stored Procedures

Supported

The Linter's internal procedural language has no other name rather than "procedural language" and PL/SQL-like scripting language

System Architecture

Shared-Everything

Views

Virtual Views Materialized Views