H2 (DBMS) - Wikipedia

Database management system

‹The template Manual is being considered for merging.› 

This article is written like a manual or guide. Please help rewrite this article and remove advice or instruction. (July 2023)

H2 Database Engine

Initial release	December 2005; 18 years ago (2005-12)
Stable release	2.3.232 / November 8, 2024; 17 days ago (2024-11-08)
Repository	github.com/h2database/h2database
Written in	Java
Operating system	Cross-platform
Type	Relational Database Management System
License	Eclipse Public License or Mozilla Public License 2.0
Website	h2database.com

H2 is a relational database management system written in Java. It can be embedded in Java applications or run in client–server mode.[1]

The software is available as open source software Mozilla Public License 2.0 or the original Eclipse Public License.[citation needed]

History

[edit]

The development of the H2 database engine started in May 2004, and first published in December 2005. The database engine was written by Thomas Mueller. He also developed the Java database engine Hypersonic SQL.[2] In 2001, the Hypersonic SQL project was stopped, and the HSQLDB Group was formed to continue work on the Hypersonic SQL code. The name H2 stands for Hypersonic 2, however H2 does not share code with Hypersonic SQL or HSQLDB. H2 is built from scratch.[3]

Main features

[edit]

Use of SQL

[edit]

A subset of the SQL (Structured Query Language) standard is supported. The main programming APIs are SQL and JDBC, however the database also supports using the PostgreSQL ODBC driver by acting like a PostgreSQL server.[4]

Table types

[edit]

It is possible to create both in-memory tables, as well as disk-based tables. Tables can be persistent or temporary. Index types are hash table and tree for in-memory tables, and b-tree for disk-based tables. All data manipulation operations are transactional. Table level locking and multiversion concurrency control are implemented. The two-phase commit protocol is supported as well, but no standard API for distributed transactions is implemented.[citation needed]

Security features

[edit]

The security features of the database are: role based access rights, encryption of the password using SHA-256 and data using the AES or the Tiny Encryption Algorithm, XTEA. The cryptographic features are available as functions inside the database as well. SSL / TLS connections are supported in the client–server mode, as well as when using the console application.[citation needed]

The database supports protection against SQL injection by enforcing the use of parameterized statements. In H2, this feature is called 'disabling literals'.[5]

Full text search capability

[edit]

Two full text search implementations are included, a native implementation and one using Lucene.[citation needed]

High availability

[edit]

A simple form of high availability is implemented: when used in the client–server mode, the database engine supports hot failover (this is commonly known as clustering). However, the clustering mode must be enabled manually after a failure.[6]

Cloud version

[edit]

Since version 1.1.111, H2 in-memory database can run inside the Google App Engine.[7]

Challenges affecting durability of relational databases

[edit]

This section is written like a personal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings or presents an original argument about a topic. Please help improve it by rewriting it in an encyclopedic style. (July 2023) (Learn how and when to remove this message)

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2023) (Learn how and when to remove this message)

The H2 documentation explains in detail several ways in which problems in underlying hardware and in particular power systems can impact durability of relational databases.

According to the H2 documentation, such problems are related not only to the DB engine design, but also to the storage caching mechanism. As storage devices use write cache in order to increase speed, in a situation of power failure, data in the device's cache is lost. Administrators have then to assess the common trade off between speed and data loss risks in the context of the business requirements and must carefully consider the design of the power supply and UPS of critical servers.

It is possible in some cases to force the storage to write cache frequently or even immediately using fsync which slows the writing process or one can accept that caching in the device buffer introduces some risk of data loss in case of power failure. The effectiveness of using fsync is limited by the fact that many HDD have write caching enabled by factory default in which case there is nothing about the design or settings of the database nor OS level commands that will be able to eliminate the chance of lost or inconsistent data in the event of a sudden power failure. Working with the OS and hardware settings to disable all caching so as to write data in real time can have significant impacts on performance in that only around 100 write operations per second would be achievable when using spinning disks.

The H2 documentation makes an effort to describe in detail [8] potential problems with durability (part of ACID) resulting from the potential data loss of committed transactions in case of a power failure.

Considering the hardware limitations regarding preservation of data in the event of sudden power loss and the ineffectiveness of approaches commonly employed by developers to prevent these sorts of losses, many database engines do not by default call FileDescriptor.sync() nor FileChannel.force() nor fsync or equivalents for every commit because they significantly degrade system performance without significantly increasing durability.

HSQLDB documentation references workarounds to a similar set of issues in their documentation.[9]

The Microsoft Knowledge Base describes the impact issues like power failures, write caching, etc. can have on performance and durability.[10] The knowledge base discusses the trade offs between performance and the vulnerability of disk write caching as well as settings that an administrator can use to balance these.

Utilities

[edit]

An embedded web server with a browser based console application is included, as well as command line tools to start and stop a server, backup and restore databases, and a command line shell tool.[citation needed]

See also

[edit]

• List of relational database management systems
• Comparison of relational database management systems
• Apache Derby
• HSQLDB

References

[edit]

1. ^ "Presentation and use of H2 Database Engine". 6 August 2010.
2. ^ Hypersonic SQL project page at SourceForge
3. ^ "Write Your Own Database, Again". thecodist.com. Archived from the original on 2019-03-07. Retrieved 2011-04-27.
4. ^ "H2 Database supports PostgreSQL ODBC driver". Archived from the original on 2016-12-09. Retrieved 2010-08-24.
5. ^ "SQL Injections: How Not To Get Stuck".
6. ^ "H2 Clustering". Archived from the original on 2010-09-24.
7. ^ "H2 Database on GAE". gaevfs.
8. ^ "Advanced". Retrieved 30 October 2014.
9. ^ "Chapter 9. SQL Syntax". Archived from the original on 19 May 2018. Retrieved 30 October 2014.
10. ^ "Slow Disk Performance When Write Caching Is Enabled". Archived from the original on 31 December 2014. Retrieved 21 December 2014.

External links

[edit]

• Official website
• H2 database tutorial