InterBase

From Wikipedia, the free encyclopedia - View original article

InterBase
Developer(s)Embarcadero Technologies
Stable release10 (XE) / 21 September 2010
Operating systemcross-platform
TypeDatabase management system
LicenseProprietary
Websitewww.embarcadero.com/products/interbase
 
Jump to: navigation, search
InterBase
Developer(s)Embarcadero Technologies
Stable release10 (XE) / 21 September 2010
Operating systemcross-platform
TypeDatabase management system
LicenseProprietary
Websitewww.embarcadero.com/products/interbase

InterBase is a relational database management system (RDBMS) currently developed and marketed by Embarcadero Technologies. InterBase is distinguished from other RDBMSs by its small footprint, close to zero administration requirements, and multi-generational architecture.[1] InterBase runs on the Microsoft Windows, Linux, Mac OS X, Solaris operating systems as well as iOS and Android.

Technology[edit]

In many respects, InterBase is quite conventional; it is a SQL-92-compliant relational database and supports standard interfaces such as JDBC, ODBC, and ADO.NET. However, certain technical features distinguish InterBase from other products.

Small footprint[edit]

A full InterBase 2009 server installation requires around 40 MB on disk. This is significantly smaller than the client installation of many competing database servers. The server uses very little memory when idle. A minimum InterBase client install requires about 400 KB of disk space.

Embedded or server[edit]

InterBase offers the option to run as an embedded database or regular server.

Minimal administration[edit]

InterBase servers typically do not require full-time database administrators.

Data controller friendly inbuilt encryption[edit]

Since InterBase XE, InterBase includes 256bit AES strength encryption that offers full database, table or column data encryption. This assist data controllers conform with data protection laws around at-rest data by providing separated encryption / db access to the database and ensuring the database file is encrypted wherever it resides. The separation of the encryption also enables developers to just develop the application rather than worry about the data visible from a specific user login.

Multi-generational architecture[edit]

Concurrency control[edit]

Consider a simple banking application where two users have access to the funds in a particular account. Bob reads the account and finds there is 1000 dollars in it, so he withdraws 500. Jane reads the same account before Bob has changed it, sees 1000 dollars, and withdraws 800. The account should be 300 dollars overdrawn, however, depending on which transaction gets processed first it will contain either 500 or 200 dollars. This poses a serious problem and needless to say, any database system with multi-user access needs some sort of system to deal with these scenarios.

The techniques used to solve this and other related problems are known in the database industry as concurrency control.

Traditional products used locks which stated that a particular transaction was going to modify a record. Once the lock was placed, no one else could read or modify the data until the lock was released. The lock may block changes to a single record, a page (a group of records stored together on disk) of records, or every record examined by a particular transaction, depending on the lock resolution. Lock resolution is a tradeoff between performance and accuracy—by blocking updates at the page level, for example, some updates will be blocked which do not in fact conflict with updates made by other transactions, but performance will be improved in comparison with record level locks.

Locking becomes an even bigger problem when combined with another feature common to all such systems, isolation. This is because transactions typically involve both a read and a write—in this example, to read the value of the account and then change it. In order to show an isolated view of the data the entire transaction, including records read but never written to, must be locked in many database servers.

In InterBase, readers do not block writers. Instead, each record in the database can exist in more than one version. For instance, when Bob and Jane read the accounts they would both get "version 1", reading 1000 dollars. When Bob then changes the account to make his withdrawal the data is not overwritten, but instead a new "version 2" will be created with 500 dollars. Jane's attempt to make her 800 dollar withdrawal will notice that there is a new version 2, and her attempt to make a withdrawal will fail.

This approach to concurrency control is called multiversion concurrency control. InterBase's implementation of multiversion concurrency control is commonly called its multi-generational architecture. InterBase was the second commercial database to use this technique; the first was DEC's Rdb/ELN.

Multiversion concurrency control also makes true snapshot transaction isolation relatively simple to implement. A transaction with snapshot isolation in InterBase shows the state of the database precisely as it was at the instant the transaction began. This is very useful for backups of an active database, long-running batch processes, and the like.

Rollbacks and recovery[edit]

InterBase also uses its multi-generational architecture to implement rollbacks. Most database servers use logs to implement the rollback feature, which can result in rollbacks taking a long time or possibly even requiring manual intervention. By contrast, InterBase's rollbacks are near-instantaneous and never fail.

Drawbacks[edit]

Certain operations are more difficult to implement in a multi-generational architecture, and hence perform slowly relative to a more traditional implementation. One example is the SQL COUNT verb. Even when an index is available on the column or columns included in the COUNT, all records must be visited in order to see if they are visible under the current transaction isolation.

History[edit]

Multiversion concurrency control before InterBase[edit]

Multiversion concurrency control is described in some detail in sections 4.3 and 5.5 of the 1981 paper "Concurrency Control in Distributed Database Systems"[2] by Philip Bernstein and Nathan Goodman—then employed by the Computer Corporation of America. Bernstein and Goodman's paper cites a 1978 dissertation[3] by D.P. Reed which quite clearly describes MVCC and claims it as an original work.

Starkey's MVCC was differed radically from the work of Reed, Bernstein, and Goodman in the handling of read/write [RW] conflicts. In Bernstein’s system, a record read by an older transaction was fatal to an attempted write by a younger, violating the principle that readers should not block writers. Starkey’s system avoided this problem by managing RW collisions without conflict so that readers would not block writers and writers would not block readers.

The MVCC system used in Starkey's InterBase was essentially identical to the system used by Starkey in his earlier Rdb/ELN product.

Early years[edit]

InterBase Software—originally known as Groton Database Systems—was born in Ann Harrison's spare room. Ann was the first junior programmer for the company and worked on nearly every component between version 0 and 3.3.[4]

Jim Starkey was working at DEC on their Datatrieve 4th generation language 4GL product when he came up with an idea for a system to manage concurrent changes by many users. The idea dramatically simplified the existing problems of locking which were proving to be a serious problem for the new relational database systems being developed at the time. Starkey, however, had the idea after he had spun off his original relational database project to another group and a turf war ensued. Starkey left the company after shipping the first version of the Rdb/ELN product.

Although InterBase's implementation is much more similar to the system described by Reed in his MIT dissertation than any other database that existed at the time and Starkey knew Bernstein from his previous position at the Computer Corporation of America and later at DEC, Starkey has stated that he arrived at the idea of multiversion concurrency control independently.[5] In the same comment, Starkey says:

The inspiration for multi-generational concurrency control was a database system done by Prime that supported page level snapshots. The intention of the feature was to give a reader a consistent view of the database without blocking writers. The idea intrigued me as a very useful characteristic of a database system.

He had heard that the local workstation vendor Apollo Computer was looking for a database offering on their Unix machines, and they agreed to fund development. With their encouragement he formed Groton Database Systems (named after the town, Groton, Massachusetts, where they were located) on Labor Day 1984 and started work on what would eventually be released as InterBase. In 1986 Apollo suffered a corporate shakeup and decided to exit the software business,[citation needed] but by this time the product was making money.

The road to Borland[edit]

Between 1986 and 1991 the product was gradually sold to Ashton-Tate, makers of the famous dBASE who were at the time purchasing various database companies in order to fill out their portfolio. The company was soon in trouble,[citation needed] and Borland purchased Ashton-Tate in 1991, acquiring InterBase as part of the deal.

Open source[edit]

In early 2000, Borland announced that InterBase would be released under open source, and began negotiations to spin off a separate company to manage the product. When the people who were to run the new company and Borland could not agree on the terms of the separation, InterBase remained a Borland product, and the source code for InterBase version 6 was released under a variant of the Mozilla Public License in mid-2000.

With the InterBase division at Borland under new management, the company released a proprietary version of InterBase version 6 and then 6.5. Borland released several updates to the open source code before announcing that it would no longer actively develop the open source project. Firebird, an open source fork of the InterBase 6 code, however, remains in active development.

In 2001, a backdoor was discovered (and fixed) in the software that had been present in all versions since 1994.[6]

CodeGear[edit]

On February 8 of 2006, Borland announced the intention to sell their line of development tool products, including InterBase, Delphi, JBuilder, and other tools [1], but instead of selling the divisions, Borland spun them out as a subsidiary on 14 November 2006. InterBase, along with IDE tools such as Delphi and JBuilder were included in the new company's product lineup. Then on 7 May 2008, Borland and Embarcadero Technologies announced that Embarcadero had "signed a definitive asset purchase agreement to purchase CodeGear."[7] The acquisition, for approximately $24.5 million, closed on 30 June 2008.[8]

Recent releases[edit]

At the end of 2002, Borland released InterBase version 7, featuring support for SMP, enhanced support for monitoring and control of the server by administrators, and more. Borland released InterBase 7.1 in June 2003, 7.5 in December 2004, and 7.5.1 on June 1, 2005.

In September 2006, Borland announced[9] the availability of InterBase 2007. Its new features include point in time recovery via journaling (which also allows recoverability without the performance penalty of synchronous writes), incremental backup, batch statement operations, new Unicode character encodings, and a new ODBC driver.

In September 2008, Embarcadero announced[10] the availability of InterBase 2009. Its new features include full database encryption, selective column-level data encryption and over-the-wire encryption offering secure TCP/IP communication via Secure Socket Layer (SSL).

In September 2010, Embarcadero announced[11] the availability of InterBase XE. Its new features include a 64 bit client and server, improved security, improved scalability, support for dynamic SQL in stored procedures, and optimized performance of large objects with stream methods.

References[edit]

External links[edit]