Non blocking operations.
In a classic RDBMS, an user modifying a tuple prevents the rest of users from viewing or altering the same record. With only one official version of the record and one temporary version being edited, this has sense. The engine must protect the consistence and reliability of the stored data. However, locking a record in a relation (table) with thousand records may be an expensive operation, depending on the internal implementation of the engine. Therefore, most RDBMS systems have locking at the page level. This means a complete page is locked when a record is edited. The page size usually is set to match the operating system's page size or a value that can be configured to improve performance. Depending on the page size and the size of each record, many records may be blocked, namely, all the records in the same page than the one being edited. In other words, writers block readers and readers may block writers if the readers keep the retrieved records inside a transaction with a high isolation level that's not closed.
The typical response of RDBMS vendors has been to raise the granularity of the locking, so it became a true per record operation and not a page level operation. This technique prevents adjacent records from being affected but does nothing to help with records edited but still uncommitted.
Interbase doesn't have these issues. It resolved things from another point of view since it was conceived. It simply doesn't lock any reader nor any writer. Don't let me wrong, this is not the chaos: if two people in their respective transactions try to update the same record at the same time, they will get an error as expected.
Interbase takes advantage of the multi generational engine to prevent readers from being blocked by writers and vice versa. Interbase always uses a transaction, be it implicit or explicit, to serve a request. Each time a record is edited and this change is posted to the database, Interbase creates a new version of the record. All other transactions operating with the record continue seeing the old version as long as they do not commit or roll back. In this way, an user perusing one table sees its newest committed version of each record. The possible even newest version of the record that remains uncommitted is enclosed and isolated in its transaction until that transaction commits or rolls back. Each time an user terminates a transaction and begins a new transaction implicitly or explicitly, he/she can see the last committed record versions in each table. Instead of working with the newest committed version of a record, the user can elect to wait for the newest uncommitted version of a record to be committed or rolled back or to see an exception (error condition) immediately if such newest uncommitted version exists. Specifying the parameters of the transaction when it's started, the user can choose to have a steady, fixed snapshot of the database, regardless of the changes other transactions make to the tables. If this doesn't suffice, the user even can decide to go against C/S principles for a short time and take complete control of some tables in the old desktop database style, by specifying that a transaction will lock with a write exclusive flag all tables it touches, so other transaction can still read but they can't modify any record. Regarding the not very technical expression "it touches", you should understand a transaction "touches" a table when any SQL command applies to that table, be it a select, insert, update or delete.
Of course, the non blocking feature not only includes updates:
 |
If a record is updated, a new version is created for the new transactions. The current transactions continue watching the prior version. |
|
If a record is deleted, a special version is created to mark it as deleted. The current transactions continue watching the current version as it was not deleted. |
|
If a record is inserted, it's visible only to the owning transaction. The current transactions continue watching records as if it didn't exist. |
The other transactions that read don't have access to these changes unless the updating transaction commits and the reader transactions:
|
Use read committed isolation level. |
|
Use a higher isolation level (snapshot) and they commit, too. |
This special feature relieves application designers from many problems and their workarounds that plague applications targeted at the most know database products in the market. Conflicts among readers and writers are almost eliminated (of course, leaving apart the case when a developer needs exclusive write access to a complete table for a brief time), so the typical deadlocks are less frequent in Interbase. Also, printing a report with a static view of the data for having consistency is one of the natural options and the default isolation level a transaction has, so the engine is not going to loss all performance in a few minutes, because this is the way it was designed to work. In other relational databases, maintaining a steady vision of the data for some time is a very expensive request for the engine.
If you want to know detailed information as well as what happens among several writers, please read about multiple concurrent transactions and the full transaction options in more detail.
Paraphrasing Microsoft, one could say "where do you want to avoid locks today?" but I prefer to look for another logo, like the legend at Interbase2000 that says "The future is upon us".