[画像:H2 database logo] ▲

Advanced

Result Sets
Large Objects
Linked Tables
Spatial Features
Recursive Queries
Updatable Views
Transaction Isolation
Multi-Version Concurrency Control (MVCC)
Clustering / High Availability
Two Phase Commit
Compatibility
Keywords / Reserved Words
Standards Compliance
Run as Windows Service
ODBC Driver
ACID
Durability Problems
Using the Recover Tool
File Locking Protocols
Using Passwords
Password Hash
Protection against SQL Injection
Protection against Remote Access
Restricting Class Loading and Usage
Security Protocols
TLS Connections
Universally Unique Identifiers (UUID)
Settings Read from System Properties
Setting the Server Bind Address
Pluggable File System
Split File System
Java Objects Serialization
Limits and Limitations
Glossary and Links

Result Sets

Statements that Return a Result Set

The following statements return a result set: SELECT, TABLE, VALUES, EXPLAIN, CALL, SCRIPT, SHOW, HELP. EXECUTE may return either a result set or an update count. Result of a WITH statement depends on inner command. All other statements return an update count.

Limiting the Number of Rows

Before the result is returned to the application, all rows are read by the database. Server side cursors are not supported currently. If only the first few rows are interesting for the application, then the result set size should be limited to improve the performance. This can be done using FETCH in a query (example: SELECT * FROM TEST FETCH FIRST 100 ROWS ONLY), or by using Statement.setMaxRows(max).

Large Result Sets and External Sorting

For large result set, the result is buffered to disk. The threshold can be defined using the statement SET MAX_MEMORY_ROWS. If ORDER BY is used, the sorting is done using an external sort algorithm. In this case, each block of rows is sorted using quick sort, then written to disk; when reading the data, the blocks are merged together.

Large Objects

Storing and Reading Large Objects

If it is possible that the objects don't fit into memory, then the data type CLOB (for textual data) or BLOB (for binary data) should be used. For these data types, the objects are not fully read into memory, by using streams. To store a BLOB, use PreparedStatement.setBinaryStream. To store a CLOB, use PreparedStatement.setCharacterStream. To read a BLOB, use ResultSet.getBinaryStream, and to read a CLOB, use ResultSet.getCharacterStream. When using the client/server mode, large BLOB and CLOB data is stored in a temporary file on the client side.

When to use CLOB/BLOB

By default, this database stores large LOB (CLOB and BLOB) objects separate from the main table data. Small LOB objects are stored in-place, the threshold can be set using MAX_LENGTH_INPLACE_LOB, but there is still an overhead to use CLOB/BLOB. Because of this, BLOB and CLOB should never be used for columns with a maximum size below about 200 bytes. The best threshold depends on the use case; reading in-place objects is faster than reading from separate files, but slows down the performance of operations that don't involve this column.

Linked Tables

This database supports linked tables, which means tables that don't exist in the current database but are just links to another database. To create such a link, use the CREATE LINKED TABLE statement:

CREATE LINKED TABLE LINK('org.postgresql.Driver', 'jdbc:postgresql:test', 'sa', 'sa', 'TEST');

You can then access the table in the usual way. Whenever the linked table is accessed, the database issues specific queries over JDBC. Using the example above, if you issue the query SELECT * FROM LINK WHERE ID=1, then the following query is run against the PostgreSQL database: SELECT * FROM TEST WHERE ID=?. The same happens for insert and update statements. Only simple statements are executed against the target database, that means no joins (queries that contain joins are converted to simple queries). Prepared statements are used where possible.

To view the statements that are executed against the target table, set the trace level to 3.

If multiple linked tables point to the same database (using the same database URL), the connection is shared. To disable this, set the system property h2.shareLinkedConnections=false.

The statement CREATE LINKED TABLE supports an optional schema name parameter.

The following are not supported because they may result in a deadlock: creating a linked table to the same database, and creating a linked table to another database using the server mode if the other database is open in the same server (use the embedded mode instead).

Data types that are not supported in H2 are also not supported for linked tables, for example unsigned data types if the value is outside the range of the signed type. In such cases, the columns needs to be cast to a supported type.

Updatable Views

By default, views are not updatable. To make a view updatable, use an "instead of" trigger as follows:

CREATE TRIGGER TRIGGER_NAME
INSTEAD OF INSERT, UPDATE, DELETE
ON VIEW_NAME
FOR EACH ROW CALL "com.acme.TriggerClassName";

Update the base table(s) within the trigger as required. For details, see the sample application org.h2.samples.UpdatableView.

Transaction Isolation

Please note that most data definition language (DDL) statements, such as "create table", commit the current transaction. See the Commands for details.

Transaction isolation is provided for all data manipulation language (DML) statements.

H2 supports read uncommitted, read committed, repeatable read, snapshot, and serializable (partially, see below) isolation levels:

• Read uncommitted
  Dirty reads, non-repeatable reads, and phantom reads are possible. To enable, execute the SQL statement SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
• Read committed
  This is the default level. Dirty reads aren't possible; non-repeatable reads and phantom reads are possible. To enable, execute the SQL statement SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL READ COMMITTED
• Repeatable read
  Dirty reads and non-repeatable reads aren't possible, phantom reads are possible. To enable, execute the SQL statement SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL REPEATABLE READ
• Snapshot
  Dirty reads, non-repeatable reads, and phantom reads aren't possible. This isolation level is very expensive in databases with many tables. To enable, execute the SQL statement SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SNAPSHOT
• Serializable
  Dirty reads, non-repeatable reads, and phantom reads aren't possible. Note that this isolation level in H2 currently doesn't ensure equivalence of concurrent and serializable execution of transactions that perform write operations. This isolation level is very expensive in databases with many tables. To enable, execute the SQL statement SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE

• Dirty reads
  Means a connection can read uncommitted changes made by another connection.
  Possible with: read uncommitted.
• Non-repeatable reads
  A connection reads a row, another connection changes a row and commits, and the first connection re-reads the same row and gets the new result.
  Possible with: read uncommitted, read committed.
• Phantom reads
  A connection reads a set of rows using a condition, another connection inserts a row that falls in this condition and commits, then the first connection re-reads using the same condition and gets the new row.
  Possible with: read uncommitted, read committed, repeatable read.

Multi-Version Concurrency Control (MVCC)

Insert and update operations only issue a shared lock on the table. An exclusive lock is still used when adding or removing columns or when dropping the table. Connections only 'see' committed data, and own changes. That means, if connection A updates a row but doesn't commit this change yet, connection B will see the old value. Only when the change is committed, the new value is visible by other connections (read committed). If multiple connections concurrently try to lock or update the same row, the database waits until it can apply the change, but at most until the lock timeout expires.

Lock Timeout

If a connection cannot get a lock on an object, the connection waits for some amount of time (the lock timeout). During this time, hopefully the connection holding the lock commits and it is then possible to get the lock. If this is not possible because the other connection does not release the lock for some time, the unsuccessful connection will get a lock timeout exception. The lock timeout can be set individually for each connection.

Clustering / High Availability

This database supports a simple clustering / high availability mechanism. The architecture is: two database servers run on two different computers, and on both computers is a copy of the same database. If both servers run, each database operation is executed on both computers. If one server fails (power, hardware or network failure), the other server can still continue to work. From this point on, the operations will be executed only on one server until the other server is back up.

Clustering can only be used in the server mode (the embedded mode does not support clustering). The cluster can be re-created using the CreateCluster tool without stopping the remaining server. Applications that are still connected are automatically disconnected, however when appending ;AUTO_RECONNECT=TRUE, they will recover from that.

To initialize the cluster, use the following steps:

• Create a database
• Use the CreateCluster tool to copy the database to another location and initialize the clustering. Afterwards, you have two databases containing the same data.
• Start two servers (one for each copy of the database)
• You are now ready to connect to the databases with the client application(s)

Using the CreateCluster Tool

To understand how clustering works, please try out the following example. In this example, the two databases reside on the same computer, but usually, the databases will be on different servers.

• Create two directories: server1, server2. Each directory will simulate a directory on a computer.
• Start a TCP server pointing to the first directory. You can do this using the command line:

  java org.h2.tools.Server
   -tcp -tcpPort 9101
   -baseDir server1
  

• Start a second TCP server pointing to the second directory. This will simulate a server running on a second (redundant) computer. You can do this using the command line:

  java org.h2.tools.Server
   -tcp -tcpPort 9102
   -baseDir server2
  

• Use the CreateCluster tool to initialize clustering. This will automatically create a new, empty database if it does not exist. Run the tool on the command line:

  java org.h2.tools.CreateCluster
   -urlSource jdbc:h2:tcp://localhost:9101/~/test
   -urlTarget jdbc:h2:tcp://localhost:9102/~/test
   -user sa
   -serverList localhost:9101,localhost:9102
  

• You can now connect to the databases using an application or the H2 Console using the JDBC URL jdbc:h2:tcp://localhost:9101,localhost:9102/~/test
• If you stop a server (by killing the process), you will notice that the other machine continues to work, and therefore the database is still accessible.
• To restore the cluster, you first need to delete the database that failed, then restart the server that was stopped, and re-run the CreateCluster tool.

Detect Which Cluster Instances are Running

To find out which cluster nodes are currently running, execute the following SQL statement:

SELECT SETTING_VALUE FROM INFORMATION_SCHEMA.SETTINGS WHERE SETTING_NAME = 'CLUSTER'

If the result is '' (two single quotes), then the cluster mode is disabled. Otherwise, the list of servers is returned, enclosed in single quote. Example: 'server1:9191,server2:9191'.

It is also possible to get the list of servers by using Connection.getClientInfo().

The property list returned from getClientInfo() contains a numServers property that returns the number of servers that are in the connection list. To get the actual servers, getClientInfo() also has properties server0..serverX, where serverX is the number of servers minus 1.

Example: To get the 2nd server in the connection list one uses getClientInfo('server1'). Note: The serverX property only returns IP addresses and ports and not hostnames.

Clustering Algorithm and Limitations

Read-only queries are only executed against the first cluster node, but all other statements are executed against all nodes. There is currently no load balancing made to avoid problems with transactions. The following functions may yield different results on different cluster nodes and must be executed with care: UUID(), RANDOM_UUID(), SECURE_RAND(), SESSION_ID(), MEMORY_FREE(), MEMORY_USED(), CSVREAD(), CSVWRITE(), RAND() [when not using a seed]. Those functions should not be used directly in modifying statements (for example INSERT, UPDATE, MERGE). However, they can be used in read-only statements and the result can then be used for modifying statements. Identity columns aren't supported. Instead, sequence values need to be manually requested and then used to insert data (using two statements).

When using the cluster modes, result sets are read fully in memory by the client, so that there is no problem if the server dies that executed the query. Result sets must fit in memory on the client side.

The SQL statement SET AUTOCOMMIT FALSE is not supported in the cluster mode. To disable autocommit, the method Connection.setAutoCommit(false) needs to be called.

It is possible that a transaction from one connection overtakes a transaction from a different connection. Depending on the operations, this might result in different results, for example when conditionally incrementing a value in a row.

Two Phase Commit

The two phase commit protocol is supported. 2-phase-commit works as follows:

• Autocommit needs to be switched off
• A transaction is started, for example by inserting a row
• The transaction is marked 'prepared' by executing the SQL statement PREPARE COMMIT transactionName
• The transaction can now be committed or rolled back
• If a problem occurs before the transaction was successfully committed or rolled back (for example because a network problem occurred), the transaction is in the state 'in-doubt'
• When re-connecting to the database, the in-doubt transactions can be listed with SELECT * FROM INFORMATION_SCHEMA.IN_DOUBT
• Each transaction in this list must now be committed or rolled back by executing COMMIT TRANSACTION transactionName or ROLLBACK TRANSACTION transactionName
• The database needs to be closed and re-opened to apply the changes

Compatibility

This database is (up to a certain point) compatible to other databases such as HSQLDB, MySQL and PostgreSQL. There are certain areas where H2 is incompatible.

Transaction Commit when Autocommit is On

At this time, this database engine commits a transaction (if autocommit is switched on) just before returning the result. For a query, this means the transaction is committed even before the application scans through the result set, and before the result set is closed. Other database engines may commit the transaction in this case when the result set is closed.

Keywords / Reserved Words

There is a list of keywords that can't be used as identifiers (table names, column names and so on), unless they are quoted (surrounded with double quotes). The following tokens are keywords in H2:

Keyword	H2	SQL Standard
		2016	2011	2008	2003	1999	92
ALL	+	+	+	+	+	+	+
AND	+	+	+	+	+	+	+
ANY	+	+	+	+	+	+	+
ARRAY	+	+	+	+	+	+
AS	+	+	+	+	+	+	+
ASYMMETRIC	+	+	+	+	+	NR
AUTHORIZATION	+	+	+	+	+	+	+
BETWEEN	+	+	+	+	+	NR	+
BOTH	CS	+	+	+	+	+	+
CASE	+	+	+	+	+	+	+
CAST	+	+	+	+	+	+	+
CHECK	+	+	+	+	+	+	+
CONSTRAINT	+	+	+	+	+	+	+
CROSS	+	+	+	+	+	+	+
CURRENT_CATALOG	+	+	+	+
CURRENT_DATE	+	+	+	+	+	+	+
CURRENT_PATH	+	+	+	+	+	+
CURRENT_ROLE	+	+	+	+	+	+
CURRENT_SCHEMA	+	+	+	+
CURRENT_TIME	+	+	+	+	+	+	+
CURRENT_TIMESTAMP	+	+	+	+	+	+	+
CURRENT_USER	+	+	+	+	+	+	+
DAY	+	+	+	+	+	+	+
DEFAULT	+	+	+	+	+	+	+
DISTINCT	+	+	+	+	+	+	+
ELSE	+	+	+	+	+	+	+
END	+	+	+	+	+	+	+
EXCEPT	+	+	+	+	+	+	+
EXISTS	+	+	+	+	+	NR	+
FALSE	+	+	+	+	+	+	+
FETCH	+	+	+	+	+	+	+
FOR	+	+	+	+	+	+	+
FOREIGN	+	+	+	+	+	+	+
FROM	+	+	+	+	+	+	+
FULL	+	+	+	+	+	+	+
GROUP	+	+	+	+	+	+	+
GROUPS	CS	+	+
HAVING	+	+	+	+	+	+	+
HOUR	+	+	+	+	+	+	+
IF	+
ILIKE	CS
IN	+	+	+	+	+	+	+
INNER	+	+	+	+	+	+	+
INTERSECT	+	+	+	+	+	+	+
INTERVAL	+	+	+	+	+	+	+
IS	+	+	+	+	+	+	+
JOIN	+	+	+	+	+	+	+
KEY	+	NR	NR	NR	NR	+	+
LEADING	CS	+	+	+	+	+	+
LEFT	+	+	+	+	+	+	+
LIKE	+	+	+	+	+	+	+
LIMIT	MS	+
LOCALTIME	+	+	+	+	+	+
LOCALTIMESTAMP	+	+	+	+	+	+
MINUS	MS
MINUTE	+	+	+	+	+	+	+
MONTH	+	+	+	+	+	+	+
NATURAL	+	+	+	+	+	+	+
NOT	+	+	+	+	+	+	+
NULL	+	+	+	+	+	+	+
OFFSET	+	+	+	+
ON	+	+	+	+	+	+	+
OR	+	+	+	+	+	+	+
ORDER	+	+	+	+	+	+	+
OVER	CS	+	+	+	+
PARTITION	CS	+	+	+	+
PRIMARY	+	+	+	+	+	+	+
QUALIFY	+
RANGE	CS	+	+	+	+
REGEXP	CS
RIGHT	+	+	+	+	+	+	+
ROW	+	+	+	+	+	+
ROWNUM	+
ROWS	CS	+	+	+	+	+	+
SECOND	+	+	+	+	+	+	+
SELECT	+	+	+	+	+	+	+
SESSION_USER	+	+	+	+	+	+
SET	+	+	+	+	+	+	+
SOME	+	+	+	+	+	+	+
SYMMETRIC	+	+	+	+	+	NR
SYSTEM_USER	+	+	+	+	+	+	+
TABLE	+	+	+	+	+	+	+
TO	+	+	+	+	+	+	+
TOP	MS CS
TRAILING	CS	+	+	+	+	+	+
TRUE	+	+	+	+	+	+	+
UESCAPE	+	+	+	+	+
UNION	+	+	+	+	+	+	+
UNIQUE	+	+	+	+	+	+	+
UNKNOWN	+	+	+	+	+	+	+
USER	+	+	+	+	+	+	+
USING	+	+	+	+	+	+	+
VALUE	+	+	+	+	+	+	+
VALUES	+	+	+	+	+	+	+
WHEN	+	+	+	+	+	+	+
WHERE	+	+	+	+	+	+	+
WINDOW	+	+	+	+	+
WITH	+	+	+	+	+	+	+
YEAR	+	+	+	+	+	+	+
_ROWID_	+

Mode-sensitive keywords (MS) are keywords only in some compatibility modes.

• LIMIT is a keywords only in Regular, Legacy, DB2, HSQLDB, MariaDB, MySQL, and PostgreSQL compatibility modes. It is an identifier in Strict, Derby, MSSQLServer, and Oracle compatibility modes.
• MINUS is a keyword only in Regular, Legacy, DB2, HSQLDB, and Oracle compatibility modes. It is an identifier in Strict, Derby, MSSQLServer, MariaDB, MySQL, and PostgreSQL compatibility modes.
• TOP is a context-sensitive keyword (can be either keyword or identifier) only in Regular, Legacy, HSQLDB, and MSSQLServer compatibility modes. It is an identifier unconditionally in Strict, Derby, DB2, MariaDB, MySQL, Oracle, and PostgreSQL compatibility modes.

Context-sensitive keywords (CS) can be used as identifiers in some places, but cannot be used as identifiers in others. Normal keywords (+) are always treated as keywords.

Most keywords in H2 are also reserved (+) or non-reserved (NR) words in the SQL Standard. Newer versions of H2 may have more keywords than older ones. Reserved words from the SQL Standard are potential candidates for keywords in future versions.

There is a compatibility setting SET NON_KEYWORDS that can be used as a temporary workaround for applications that use keywords as unquoted identifiers.

Standards Compliance

This database tries to be as much standard compliant as possible. For the SQL language, ANSI/ISO is the main standard. There are several versions that refer to the release date: SQL-92, SQL:1999, and SQL:2003. Unfortunately, the standard documentation is not freely available. Another problem is that important features are not standardized. Whenever this is the case, this database tries to be compatible to other databases.

Supported Character Sets, Character Encoding, and Unicode

H2 internally uses Unicode, and supports all character encoding systems and character sets supported by the virtual machine you use.

Run as Windows Service

Using a native wrapper / adapter, Java applications can be run as a Windows Service. There are various tools available to do that. The Java Service Wrapper from Tanuki Software, Inc. is included in the installation. Batch files are provided to install, start, stop and uninstall the H2 Database Engine Service. This service contains the TCP Server and the H2 Console web application. The batch files are located in the directory h2/service.

The service wrapper bundled with H2 is a 32-bit version. To use a 64-bit version of Windows (x64), you need to use a 64-bit version of the wrapper, for example the one from Simon Krenger.

When running the database as a service, absolute path should be used. Using ~ in the database URL is problematic in this case, because it means to use the home directory of the current user. The service might run without or with the wrong user, so that the database files might end up in an unexpected place.

Install the Service

The service needs to be registered as a Windows Service first. To do that, double click on 1_install_service.bat. If successful, a command prompt window will pop up and disappear immediately. If not, a message will appear.

Start the Service

You can start the H2 Database Engine Service using the service manager of Windows, or by double clicking on 2_start_service.bat. Please note that the batch file does not print an error message if the service is not installed.

Connect to the H2 Console

After installing and starting the service, you can connect to the H2 Console application using a browser. Double clicking on 3_start_browser.bat to do that. The default port (8082) is hard coded in the batch file.

Stop the Service

To stop the service, double click on 4_stop_service.bat. Please note that the batch file does not print an error message if the service is not installed or started.

Uninstall the Service

To uninstall the service, double click on 5_uninstall_service.bat. If successful, a command prompt window will pop up and disappear immediately. If not, a message will appear.

Additional JDBC drivers

To use other databases (for example MySQL), the location of the JDBC drivers of those databases need to be added to the environment variables H2DRIVERS or CLASSPATH before installing the service. Multiple drivers can be set; each entry needs to be separated with a ; (Windows) or : (other operating systems). Spaces in the path names are supported. The settings must not be quoted.

ODBC Driver

This database does not come with its own ODBC driver at this time, but it supports the PostgreSQL network protocol. Therefore, the PostgreSQL ODBC driver can be used. Support for the PostgreSQL network protocol is quite new and should be viewed as experimental. It should not be used for production applications.

To use the PostgreSQL ODBC driver on 64 bit versions of Windows, first run c:/windows/syswow64/odbcad32.exe. At this point you set up your DSN just like you would on any other system. See also: Re: ODBC Driver on Windows 64 bit

ODBC Installation

First, the ODBC driver must be installed. Any recent PostgreSQL ODBC driver should work, however version 8.2 (psqlodbc-08_02*) or newer is recommended. The Windows version of the PostgreSQL ODBC driver is available at https://www.postgresql.org/ftp/odbc/versions/msi/.

Starting the Server

After installing the ODBC driver, start the H2 Server using the command line:

java -cp h2*.jar org.h2.tools.Server

The PG Server (PG for PostgreSQL protocol) is started as well. By default, databases are stored in the current working directory where the server is started. Use -baseDir to save databases in another directory, for example the user home directory:

java -cp h2*.jar org.h2.tools.Server -baseDir ~

The PG server can be started and stopped from within a Java application as follows:

Server server = Server.createPgServer("-baseDir", "~");
server.start();
...
server.stop();

By default, only connections from localhost are allowed. To allow remote connections, use -pgAllowOthers when starting the server.

To map an ODBC database name to a different JDBC database name, use the option -key when starting the server. Please note only one mapping is allowed. The following will map the ODBC database named TEST to the database URL jdbc:h2:~/data/test;cipher=aes:

java org.h2.tools.Server -pg -key TEST "~/data/test;cipher=aes"

ODBC Configuration

After installing the driver, a new Data Source must be added. In Windows, run odbcad32.exe to open the Data Source Administrator. Then click on 'Add...' and select the PostgreSQL Unicode driver. Then click 'Finish'. You will be able to change the connection properties. The property column represents the property key in the odbc.ini file (which may be different from the GUI).

Property	Example	Remarks
Data Source	H2 Test	The name of the ODBC Data Source
Database	~/test;ifexists=true	The database name. This can include connections settings. By default, the database is stored in the current working directory where the Server is started except when the -baseDir setting is used. The name must be at least 3 characters.
Servername	localhost	The server name or IP address. By default, only remote connections are allowed
Username	sa	The database user name.
SSL	false (disabled)	At this time, SSL is not supported.
Port	5435	The port where the PG Server is listening.
Password	sa	The database password.

To improve performance, please enable 'server side prepare' under Options / Datasource / Page 2 / Server side prepare.

Afterwards, you may use this data source.

PG Protocol Support Limitations

At this time, only a subset of the PostgreSQL network protocol is implemented. Also, there may be compatibility problems on the SQL level, with the catalog, or with text encoding. Problems are fixed as they are found. Currently, statements can not be canceled when using the PG protocol. Also, H2 does not provide index meta over ODBC.

PostgreSQL ODBC Driver Setup requires a database password; that means it is not possible to connect to H2 databases without password. This is a limitation of the ODBC driver.

Security Considerations

Currently, the PG Server does not support challenge response or encrypt passwords. This may be a problem if an attacker can listen to the data transferred between the ODBC driver and the server, because the password is readable to the attacker. Also, it is currently not possible to use encrypted SSL connections. Therefore the ODBC driver should not be used where security is important.

The first connection that opens a database using the PostgreSQL server needs to be an administrator user. Subsequent connections don't need to be opened by an administrator.

Using Microsoft Access

When using Microsoft Access to edit data in a linked H2 table, you may need to enable the following option: Tools - Options - Edit/Find - ODBC fields.

ACID

In the database world, ACID stands for:

• Atomicity: transactions must be atomic, meaning either all tasks are performed or none.
• Consistency: all operations must comply with the defined constraints.
• Isolation: transactions must be isolated from each other.
• Durability: committed transaction will not be lost.

Atomicity

Transactions in this database are always atomic.

Consistency

By default, this database is always in a consistent state. Referential integrity rules are enforced except when explicitly disabled.

Isolation

For H2, as with most other database systems, the default isolation level is 'read committed'. This provides better performance, but also means that transactions are not completely isolated. H2 supports the transaction isolation levels 'read uncommitted', 'read committed', 'repeatable read', and 'serializable'.

Durability

This database does not guarantee that all committed transactions survive a power failure. Tests show that all databases sometimes lose transactions on power failure (for details, see below). Where losing transactions is not acceptable, a laptop or UPS (uninterruptible power supply) should be used. If durability is required for all possible cases of hardware failure, clustering should be used, such as the H2 clustering mode.

Durability Problems

Complete durability means all committed transaction survive a power failure. Some databases claim they can guarantee durability, but such claims are wrong. A durability test was run against H2, HSQLDB, PostgreSQL, and Derby. All of those databases sometimes lose committed transactions. The test is included in the H2 download, see org.h2.test.poweroff.Test.

Ways to (Not) Achieve Durability

Making sure that committed transactions are not lost is more complicated than it seems first. To guarantee complete durability, a database must ensure that the log record is on the hard drive before the commit call returns. To do that, databases use different methods. One is to use the 'synchronous write' file access mode. In Java, RandomAccessFile supports the modes rws and rwd:

• rwd: every update to the file's content is written synchronously to the underlying storage device.
• rws: in addition to rwd, every update to the metadata is written synchronously.

A test (org.h2.test.poweroff.TestWrite) with one of those modes achieves around 50 thousand write operations per second. Even when the operating system write buffer is disabled, the write rate is around 50 thousand operations per second. This feature does not force changes to disk because it does not flush all buffers. The test updates the same byte in the file again and again. If the hard drive was able to write at this rate, then the disk would need to make at least 50 thousand revolutions per second, or 3 million RPM (revolutions per minute). There are no such hard drives. The hard drive used for the test is about 7200 RPM, or about 120 revolutions per second. There is an overhead, so the maximum write rate must be lower than that.

Calling fsync flushes the buffers. There are two ways to do that in Java:

• FileDescriptor.sync(). The documentation says that this forces all system buffers to synchronize with the underlying device. This method is supposed to return after all in-memory modified copies of buffers associated with this file descriptor have been written to the physical medium.
• FileChannel.force(). This method is supposed to force any updates to this channel's file to be written to the storage device that contains it.

By default, MySQL calls fsync for each commit. When using one of those methods, only around 60 write operations per second can be achieved, which is consistent with the RPM rate of the hard drive used. Unfortunately, even when calling FileDescriptor.sync() or FileChannel.force(), data is not always persisted to the hard drive, because most hard drives do not obey fsync(): see Your Hard Drive Lies to You. In Mac OS X, fsync does not flush hard drive buffers. See Bad fsync?. So the situation is confusing, and tests prove there is a problem.

Trying to flush hard drive buffers is hard, and if you do the performance is very bad. First you need to make sure that the hard drive actually flushes all buffers. Tests show that this can not be done in a reliable way. Then the maximum number of transactions is around 60 per second. Because of those reasons, the default behavior of H2 is to delay writing committed transactions.

In H2, after a power failure, a bit more than one second of committed transactions may be lost. To change the behavior, use SET WRITE_DELAY and CHECKPOINT SYNC. Most other databases support commit delay as well. In the performance comparison, commit delay was used for all databases that support it.

Running the Durability Test

To test the durability / non-durability of this and other databases, you can use the test application in the package org.h2.test.poweroff. Two computers with network connection are required to run this test. One computer just listens, while the test application is run (and power is cut) on the other computer. The computer with the listener application opens a TCP/IP port and listens for an incoming connection. The second computer first connects to the listener, and then created the databases and starts inserting records. The connection is set to 'autocommit', which means after each inserted record a commit is performed automatically. Afterwards, the test computer notifies the listener that this record was inserted successfully. The listener computer displays the last inserted record number every 10 seconds. Now, switch off the power manually, then restart the computer, and run the application again. You will find out that in most cases, none of the databases contains all the records that the listener computer knows about. For details, please consult the source code of the listener and test application.

Using the Recover Tool

Traditional 2-phase Recover

The Recover tool can be used to extract the contents of a database file, even if the database is corrupted. It also extracts the content of the transaction log and large objects (CLOB or BLOB). To run the tool, type on the command line:

java -cp h2*.jar org.h2.tools.Recover

For each database in the current directory, a text-dump file (*.mv.txt) and a SQL script file (*.h2.sql) will be created. Those uncompressed files are rather large, taking approximately twice the filespace of the database.

The SQL script file contains raw insert statements (for the data) and data definition (DDL) statements to recreate the schema of the database. This file can be executed using the RunScript tool or a RUNSCRIPT SQL statement. The script includes at least one CREATE USER statement. If you run the script against a database that was created with the same user, or if there are conflicting users, running the script will fail. Consider running the script against a database that was created with a username that is not in the script.

To verify the database can recover at any time, append ;RECOVER_TEST=64 to the database URL in your test environment. This will simulate an application crash after each 64 writes to the database file. A log file named databaseName.h2.db.log is created that lists the operations. The recovery is tested using an in-memory file system, that means it may require a larger heap setting.

Direct Recover

Since H2-2.3.239 there is an enhanced DirectRecover tool which features:

• Direct output into SQL-script (using a pipe)
• Compression using ZIP, GZIP, KANZI (when in classpath) or BZip2 (when in classpath)

Especially KANZI can be useful for very large databases on servers with many CPU cores as it yields in very small SQL script files. Its compression ratio beats BZip2 at a much faster speed.

# Database: testdb.mv.db (1.7GB)
# parallel compression using KANZI from https://github.com/flanglet/kanzi
java -Xmx8g -cp "h2-2.3.239-SNAPSHOT.jar:kanzi-2.4.0.jar" org.h2.tools.DirectRecover -dir ~/ -db testdb -compress kanzi
# serial compression using BZip2 from https://dlcdn.apache.org/commons/compress/binaries/
java -Xmx8g -cp "h2-2.3.239-SNAPSHOT.jar:commons-compress-1.28.0.jar" org.h2.tools.DirectRecover -dir ~/ -db testdb -compress bzip2
# serial compression using GZIP w/o any additional libraries
java -Xmx8g -cp "h2-2.3.239-SNAPSHOT.jar" org.h2.tools.DirectRecover -dir ~/ -db testdb -compress gzip
# resulting SQL script files on a AMD Zen3 Ryzen5:
# KANZI: testdb.h2.sql.knz ( 99.7 MB in 106 secs)
# BZip2: testdb.h2.sql.bz2 (153.7 MB in 18 mins)
# GZip: testdb.h2.sql.gz (207.4 MB in 74 secs)

Since H2-2.3.239 the RunScript tool can read the KANZI or BZip2 compressed script files directly when the libraries are added to the classpath:

#KANZI from https://github.com/flanglet/kanzi
java -Xmx8G -cp "h2-2.3.239-SNAPSHOT.jar:kanzi-2.4.0.jar" org.h2.tools.RunScript -url jdbc:h2:~/testdb -user sa -script ~/testdb.h2.sql.knz -options "COMPRESSION kanzi"
#BZIP2 from https://dlcdn.apache.org/commons/compress/binaries/
java -Xmx8G -cp "h2-2.3.239-SNAPSHOT.jar:commons-compress-1.28.0.jar" org.h2.tools.RunScript -url jdbc:h2:~/testdb -user sa -script ~/testdb.h2.sql.bz2 -options "COMPRESSION bzip2"

File Locking Protocols

Multiple concurrent connections to the same database are supported, however a database file can only be open for reading and writing (in embedded mode) by one process at the same time. Otherwise, the processes would overwrite each others data and corrupt the database file. To protect against this problem, whenever a database is opened, a lock file is created to signal other processes that the database is in use. If the database is closed, or if the process that opened the database stops normally, this lock file is deleted.

In special cases (if the process did not terminate normally, for example because there was a power failure), the lock file is not deleted by the process that created it. That means the existence of the lock file is not a safe protocol for file locking. However, this software uses a challenge-response protocol to protect the database files. There are two methods (algorithms) implemented to provide both security (that is, the same database files cannot be opened by two processes at the same time) and simplicity (that is, the lock file does not need to be deleted manually by the user). The two methods are 'file method' and 'socket methods'.

The file locking protocols (except the file locking method 'FS') have the following limitation: if a shared file system is used, and the machine with the lock owner is sent to sleep (standby or hibernate), another machine may take over. If the machine that originally held the lock wakes up, the database may become corrupt. If this situation can occur, the application must ensure the database is closed when the application is put to sleep.

File Locking Method 'File'

The default method for database file locking for version 1.3 and older is the 'File Method'. The algorithm is:

• If the lock file does not exist, it is created (using the atomic operation File.createNewFile). Then, the process waits a little bit (20 ms) and checks the file again. If the file was changed during this time, the operation is aborted. This protects against a race condition when one process deletes the lock file just after another one create it, and a third process creates the file again. It does not occur if there are only two writers.
• If the file can be created, a random number is inserted together with the locking method ('file'). Afterwards, a watchdog thread is started that checks regularly (every second once by default) if the file was deleted or modified by another (challenger) thread / process. Whenever that occurs, the file is overwritten with the old data. The watchdog thread runs with high priority so that a change to the lock file does not get through undetected even if the system is very busy. However, the watchdog thread does use very little resources (CPU time), because it waits most of the time. Also, the watchdog only reads from the hard disk and does not write to it.
• If the lock file exists and was recently modified, the process waits for some time (up to two seconds). If it was still changed, an exception is thrown (database is locked). This is done to eliminate race conditions with many concurrent writers. Afterwards, the file is overwritten with a new version (challenge). After that, the thread waits for 2 seconds. If there is a watchdog thread protecting the file, he will overwrite the change and this process will fail to lock the database. However, if there is no watchdog thread, the lock file will still be as written by this thread. In this case, the file is deleted and atomically created again. The watchdog thread is started in this case and the file is locked.

This algorithm is tested with over 100 concurrent threads. In some cases, when there are many concurrent threads trying to lock the database, they block each other (meaning the file cannot be locked by any of them) for some time. However, the file never gets locked by two threads at the same time. However using that many concurrent threads / processes is not the common use case. Generally, an application should throw an error to the user if it cannot open a database, and not try again in a (fast) loop.

File Locking Method 'Socket'

There is a second locking mechanism implemented, but disabled by default. To use it, append ;FILE_LOCK=SOCKET to the database URL. The algorithm is:

• If the lock file does not exist, it is created. Then a server socket is opened on a defined port, and kept open. The port and IP address of the process that opened the database is written into the lock file.
• If the lock file exists, and the lock method is 'file', then the software switches to the 'file' method.
• If the lock file exists, and the lock method is 'socket', then the process checks if the port is in use. If the original process is still running, the port is in use and this process throws an exception (database is in use). If the original process died (for example due to a power failure, or abnormal termination of the virtual machine), then the port was released. The new process deletes the lock file and starts again.

This method does not require a watchdog thread actively polling (reading) the same file every second. The problem with this method is, if the file is stored on a network share, two processes (running on different computers) could still open the same database files, if they do not have a direct TCP/IP connection.

File Locking Method 'FS'

This is the default mode for version 1.4 and newer. This database file locking mechanism uses native file system lock on the database file. No *.lock.db file is created in this case, and no background thread is started. This mechanism may not work on all systems as expected. Some systems allow to lock the same file multiple times within the same virtual machine, and on some system native file locking is not supported or files are not unlocked after a power failure.

To enable this feature, append ;FILE_LOCK=FS to the database URL.

This feature is relatively new. When using it for production, please ensure your system does in fact lock files as expected.

Using Passwords

Using Secure Passwords

Remember that weak passwords can be broken regardless of the encryption and security protocols. Don't use passwords that can be found in a dictionary. Appending numbers does not make passwords secure. A way to create good passwords that can be remembered is: take the first letters of a sentence, use upper and lower case characters, and creatively include special characters (but it's more important to use a long password than to use special characters). Example:

i'sE2rtPiUKtT from the sentence it's easy to remember this password if you know the trick.

Passwords: Using Char Arrays instead of Strings

Java strings are immutable objects and cannot be safely 'destroyed' by the application. After creating a string, it will remain in the main memory of the computer at least until it is garbage collected. The garbage collection cannot be controlled by the application, and even if it is garbage collected the data may still remain in memory. It might also be possible that the part of memory containing the password is swapped to disk (if not enough main memory is available), which is a problem if the attacker has access to the swap file of the operating system.

It is a good idea to use char arrays instead of strings for passwords. Char arrays can be cleared (filled with zeros) after use, and therefore the password will not be stored in the swap file.

This database supports using char arrays instead of string to pass user and file passwords. The following code can be used to do that:

import java.sql.*;
import java.util.*;
public class Test {
 public static void main(String[] args) throws Exception {
 String url = "jdbc:h2:~/test";
 Properties prop = new Properties();
 prop.setProperty("user", "sa");
 System.out.print("Password?");
 char[] password = System.console().readPassword();
 prop.put("password", password);
 Connection conn = null;
 try {
 conn = DriverManager.getConnection(url, prop);
 } finally {
 Arrays.fill(password, (char) 0);
 }
 conn.close();
 }
}

When using Swing, use javax.swing.JPasswordField.

Passing the User Name and/or Password in the URL

Instead of passing the user name as a separate parameter as in Connection conn = DriverManager. getConnection("jdbc:h2:~/test", "sa", "123"); the user name (and/or password) can be supplied in the URL itself: Connection conn = DriverManager. getConnection("jdbc:h2:~/test;USER=sa;PASSWORD=123"); The settings in the URL override the settings passed as a separate parameter.

Password Hash

Sometimes the database password needs to be stored in a configuration file (for example in the web.xml file). In addition to connecting with the plain text password, this database supports connecting with the password hash. This means that only the hash of the password (and not the plain text password) needs to be stored in the configuration file. This will only protect others from reading or re-constructing the plain text password (even if they have access to the configuration file); it does not protect others from accessing the database using the password hash.

To connect using the password hash instead of plain text password, append ;PASSWORD_HASH=TRUE to the database URL, and replace the password with the password hash. To calculate the password hash from a plain text password, run the following command within the H2 Console tool: @password_hash <upperCaseUserName> <password>. As an example, if the user name is sa and the password is test, run the command @password_hash SA test. Then use the resulting password hash as you would use the plain text password. When using an encrypted database, then the user password and file password need to be hashed separately. To calculate the hash of the file password, run: @password_hash file <filePassword>.

Protection against SQL Injection

What is SQL Injection

This database engine provides a solution for the security vulnerability known as 'SQL Injection'. Here is a short description of what SQL injection means. Some applications build SQL statements with embedded user input such as:

String sql = "SELECT * FROM USERS WHERE PASSWORD='"+pwd+"'";
ResultSet rs = conn.createStatement().executeQuery(sql);

If this mechanism is used anywhere in the application, and user input is not correctly filtered or encoded, it is possible for a user to inject SQL functionality or statements by using specially built input such as (in this example) this password: ' OR ''='. In this case the statement becomes:

SELECT * FROM USERS WHERE PASSWORD='' OR ''='';

Which is always true no matter what the password stored in the database is. For more information about SQL Injection, see Glossary and Links.

Disabling Literals

SQL Injection is not possible if user input is not directly embedded in SQL statements. A simple solution for the problem above is to use a prepared statement:

String sql = "SELECT * FROM USERS WHERE PASSWORD=?";
PreparedStatement prep = conn.prepareStatement(sql);
prep.setString(1, pwd);
ResultSet rs = prep.executeQuery();

This database provides a way to enforce usage of parameters when passing user input to the database. This is done by disabling embedded literals in SQL statements. To do this, execute the statement:

SET ALLOW_LITERALS NONE;

Afterwards, SQL statements with text and number literals are not allowed any more. That means, SQL statement of the form WHERE NAME='abc' or WHERE CustomerId=10 will fail. It is still possible to use prepared statements and parameters as described above. Also, it is still possible to generate SQL statements dynamically, and use the Statement API, as long as the SQL statements do not include literals. There is also a second mode where number literals are allowed: SET ALLOW_LITERALS NUMBERS. To allow all literals, execute SET ALLOW_LITERALS ALL (this is the default setting). Literals can only be enabled or disabled by an administrator.

Using Constants

Disabling literals also means disabling hard-coded 'constant' literals. This database supports defining constants using the CREATE CONSTANT command. Constants can be defined only when literals are enabled, but used even when literals are disabled. To avoid name clashes with column names, constants can be defined in other schemas:

CREATE SCHEMA CONST AUTHORIZATION SA;
CREATE CONSTANT CONST.ACTIVE VALUE 'Active';
CREATE CONSTANT CONST.INACTIVE VALUE 'Inactive';
SELECT * FROM USERS WHERE TYPE=CONST.ACTIVE;

Even when literals are enabled, it is better to use constants instead of hard-coded number or text literals in queries or views. With constants, typos are found at compile time, the source code is easier to understand and change.

Using the ZERO() Function

It is not required to create a constant for the number 0 as there is already a built-in function ZERO():

SELECT * FROM USERS WHERE LENGTH(PASSWORD)=ZERO();

Protection against Remote Access

By default this database does not allow connections from other machines when starting the H2 Console, the TCP server, or the PG server. Remote access can be enabled using the command line options -webAllowOthers, -tcpAllowOthers, -pgAllowOthers.

If you enable remote access using -tcpAllowOthers or -pgAllowOthers, please also consider using the options -baseDir, so that remote users can not create new databases or access existing databases with weak passwords. When using the option -baseDir, only databases within that directory may be accessed. Ensure the existing accessible databases are protected using strong passwords.

If you enable remote access using -webAllowOthers, please ensure the web server can only be accessed from trusted networks. If this option is specified, -webExternalNames should be also specified with comma-separated list of external names or addresses of this server. The options -baseDir don't protect access to the saved connection settings, or access to other databases accessible from the system.

Restricting Class Loading and Usage

By default there is no restriction on loading classes and executing Java code for admins. That means an admin may call system functions such as System.setProperty by executing:

CREATE ALIAS SET_PROPERTY FOR "java.lang.System.setProperty";
CALL SET_PROPERTY('abc', '1');
CREATE ALIAS GET_PROPERTY FOR "java.lang.System.getProperty";
CALL GET_PROPERTY('abc');

To restrict users (including admins) from loading classes and executing code, the list of allowed classes can be set in the system property h2.allowedClasses in the form of a comma separated list of classes or patterns (items ending with *). By default all classes are allowed. Example:

java -Dh2.allowedClasses=java.lang.Math,com.acme.*

This mechanism is used for all user classes, including database event listeners, trigger classes, user-defined functions, user-defined aggregate functions, and JDBC driver classes (with the exception of the H2 driver) when using the H2 Console.

Security Protocols

The following paragraphs document the security protocols used in this database. These descriptions are very technical and only intended for security experts that already know the underlying security primitives.

User Password Encryption

When a user tries to connect to a database, the combination of user name, @, and password are hashed using SHA-256, and this hash value is transmitted to the database. This step does not protect against an attacker that re-uses the value if he is able to listen to the (unencrypted) transmission between the client and the server. But, the passwords are never transmitted as plain text, even when using an unencrypted connection between client and server. That means if a user reuses the same password for different things, this password is still protected up to some point. See also 'RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication' for more information.

When a new database or user is created, a new random salt value is generated. The size of the salt is 64 bits. Using the random salt reduces the risk of an attacker pre-calculating hash values for many different (commonly used) passwords.

The combination of user-password hash value (see above) and salt is hashed using SHA-256. The resulting value is stored in the database. When a user tries to connect to the database, the database combines user-password hash value with the stored salt value and calculates the hash value. Other products use multiple iterations (hash the hash value again and again), but this is not done in this product to reduce the risk of denial of service attacks (where the attacker tries to connect with bogus passwords, and the server spends a lot of time calculating the hash value for each password). The reasoning is: if the attacker has access to the hashed passwords, he also has access to the data in plain text, and therefore does not need the password any more. If the data is protected by storing it on another computer and only accessible remotely, then the iteration count is not required at all.

File Encryption

The database files can be encrypted using the AES-128 algorithm.

When a user tries to connect to an encrypted database, the combination of file@ and the file password is hashed using SHA-256. This hash value is transmitted to the server.

When a new database file is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bits. The combination of the file password hash and the salt value is hashed 1024 times using SHA-256. The reason for the iteration is to make it harder for an attacker to calculate hash values for common passwords.

The resulting hash value is used as the key for the block cipher algorithm. Then, an initialization vector (IV) key is calculated by hashing the key again using SHA-256. This is to make sure the IV is unknown to the attacker. The reason for using a secret IV is to protect against watermark attacks.

Before saving a block of data (each block is 8 bytes long), the following operations are executed: first, the IV is calculated by encrypting the block number with the IV key (using the same block cipher algorithm). This IV is combined with the plain text using XOR. The resulting data is encrypted using the AES-128 algorithm.

When decrypting, the operation is done in reverse. First, the block is decrypted using the key, and then the IV is calculated combined with the decrypted text using XOR.

Therefore, the block cipher mode of operation is CBC (cipher-block chaining), but each chain is only one block long. The advantage over the ECB (electronic codebook) mode is that patterns in the data are not revealed, and the advantage over multi block CBC is that flipped cipher text bits are not propagated to flipped plaintext bits in the next block.

Database encryption is meant for securing the database while it is not in use (stolen laptop and so on). It is not meant for cases where the attacker has access to files while the database is in use. When he has write access, he can for example replace pieces of files with pieces of older versions and manipulate data like this.

File encryption slows down the performance of the database engine. Compared to unencrypted mode, database operations take about 2.5 times longer using AES (embedded mode).

Wrong Password / User Name Delay

To protect against remote brute force password attacks, the delay after each unsuccessful login gets double as long. Use the system properties h2.delayWrongPasswordMin and h2.delayWrongPasswordMax to change the minimum (the default is 250 milliseconds) or maximum delay (the default is 4000 milliseconds, or 4 seconds). The delay only applies for those using the wrong password. Normally there is no delay for a user that knows the correct password, with one exception: after using the wrong password, there is a delay of up to (randomly distributed) the same delay as for a wrong password. This is to protect against parallel brute force attacks, so that an attacker needs to wait for the whole delay. Delays are synchronized. This is also required to protect against parallel attacks.

There is only one exception message for both wrong user and for wrong password, to make it harder to get the list of user names. It is not possible from the stack trace to see if the user name was wrong or the password.

HTTPS Connections

The web server supports HTTP and HTTPS connections using SSLServerSocket. There is a default self-certified certificate to support an easy starting point, but custom certificates are supported as well.

TLS Connections

Remote TLS connections are supported using the Java Secure Socket Extension (SSLServerSocket, SSLSocket).

To use your own keystore, set the system properties javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword before starting the H2 server and client. See also Customizing the Default Key and Trust Stores, Store Types, and Store Passwords for more information.

Universally Unique Identifiers (UUID)

This database supports UUIDs. Also supported is a function to create new UUIDs using a cryptographically strong pseudo random number generator.

With random UUIDs, the chance of two having the same value can be calculated using the probability theory. See also 'Birthday Paradox'.

RFC 9562-compliant randomly generated UUIDs with version 4 have 122 random bits. 4 bits are used for the version (Randomly generated UUID), and 2 bits for the variant (Leach-Salz). This database supports generating such UUIDs using the built-in function RANDOM_UUID(4). Please note that indexes on UUIDs with this version may have a poor performance. Here is a small program to estimate the probability of having two identical UUIDs after generating a number of values:

public class Test {
 public static void main(String[] args) throws Exception {
 double x = Math.pow(2, 122);
 for (int i = 35; i < 62; i++) {
 double n = Math.pow(2, i);
 double p = 1 - Math.exp(-(n * n) / 2 / x);
 System.out.println("2^" + i + "=" + (1L << i) +
 " probability: 0" +
 String.valueOf(1 + p).substring(1));
 }
 }
}

Some values are:

Number of UUIs	Probability of Duplicates
2^36=68'719'476'736	0.000'000'000'000'000'4
2^41=2'199'023'255'552	0.000'000'000'000'4
2^46=70'368'744'177'664	0.000'000'000'4

To help non-mathematicians understand what those numbers mean, here a comparison: one's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.000'000'000'06.

RFC 9562-compliant time-ordered UUIDs with version 7 have layout optimized for database systems. They contain 48-bit number of milliseconds seconds since midnight 1 Jan 1970 UTC with leap seconds excluded and additional 12-bit sub-millisecond timestamp fraction plus 62 random bits or 74 random bits without this fraction depending on implementation.

This database supports generating such UUIDs using the built-in function RANDOM_UUID(7). This function produces 12-bit sub-millisecond timestamp fraction if high resolution timestamps are available in JVM and 62 pseudo random bits.

Spatial Features

H2 supports the geometry data type and spatial indexes. Here is an example SQL script to create a table with a spatial column and index:

CREATE TABLE GEO_TABLE(
 GID BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 THE_GEOM GEOMETRY);
INSERT INTO GEO_TABLE(THE_GEOM) VALUES
 ('POINT(500 505)'),
 ('LINESTRING(550 551, 525 512, 565 566)'),
 ('POLYGON ((550 521, 580 540, 570 564, 512 566, 550 521))');
CREATE SPATIAL INDEX GEO_TABLE_SPATIAL_INDEX
 ON GEO_TABLE(THE_GEOM);

To query the table using geometry envelope intersection, use the operation &&, as in PostGIS:

SELECT * FROM GEO_TABLE
 WHERE THE_GEOM &&
 'POLYGON ((490 490, 536 490, 536 515, 490 515, 490 490))';

You can verify that the spatial index is used using the "explain plan" feature:

EXPLAIN SELECT * FROM GEO_TABLE
 WHERE THE_GEOM &&
 'POLYGON ((490 490, 536 490, 536 515, 490 515, 490 490))';
-- Result
SELECT
 "PUBLIC"."GEO_TABLE"."GID",
 "PUBLIC"."GEO_TABLE"."THE_GEOM"
FROM "PUBLIC"."GEO_TABLE"
 /* PUBLIC.GEO_TABLE_SPATIAL_INDEX: THE_GEOM &&
 GEOMETRY 'POLYGON ((490 490, 536 490, 536 515, 490 515, 490 490))' */
WHERE "THE_GEOM" &&
 GEOMETRY 'POLYGON ((490 490, 536 490, 536 515, 490 515, 490 490))'

For persistent databases, the spatial index is stored on disk; for in-memory databases, the index is kept in memory.

Recursive Queries

H2 has experimental support for recursive queries using so called "common table expressions" (CTE). Examples:

WITH RECURSIVE T(N) AS (
 SELECT 1
 UNION ALL
 SELECT N+1 FROM T WHERE N<10
)
SELECT * FROM T;
-- returns the values 1 .. 10
WITH RECURSIVE T(N) AS (
 SELECT 1
 UNION ALL
 SELECT N*2 FROM T WHERE N<10
)
SELECT * FROM T;
-- returns the values 1, 2, 4, 8, 16
CREATE TABLE FOLDER(ID INT PRIMARY KEY, NAME VARCHAR(255), PARENT INT);
INSERT INTO FOLDER VALUES(1, null, null), (2, 'src', 1),
(3, 'main', 2), (4, 'org', 3), (5, 'test', 2);
WITH LINK(ID, NAME, LEVEL) AS (
 SELECT ID, NAME, 0 FROM FOLDER WHERE PARENT IS NULL
 UNION ALL
 SELECT FOLDER.ID, COALESCE(LINK.NAME || '/', '') || FOLDER.NAME, LEVEL + 1
 FROM LINK INNER JOIN FOLDER ON LINK.ID = FOLDER.PARENT
)
SELECT NAME FROM LINK WHERE NAME IS NOT NULL ORDER BY ID;
-- src
-- src/main
-- src/main/org
-- src/test

Limitations: Recursive queries need to be of the type UNION ALL, and the recursion needs to be on the second part of the query. No tables or views with the name of the table expression may exist. Different table expression names need to be used when using multiple distinct table expressions within the same transaction and for the same session. All columns of the table expression are of type VARCHAR, and may need to be cast to the required data type. Views with recursive queries are not supported. Subqueries and INSERT INTO ... FROM with recursive queries are not supported. Parameters are only supported within the last SELECT statement (a workaround is to use session variables like @start within the table expression). The syntax is:

WITH RECURSIVE recursiveQueryName(columnName, ...) AS (
 nonRecursiveSelect
 UNION ALL
 recursiveSelect
)
select

Settings Read from System Properties

Some settings of the database can be set on the command line using -DpropertyName=value. It is usually not required to change those settings manually. The settings are case sensitive. Example:

java -Dh2.serverCachedObjects=256 org.h2.tools.Server

The current value of the settings can be read in the table INFORMATION_SCHEMA.SETTINGS.

For a complete list of settings, see SysProperties.

Setting the Server Bind Address

Usually server sockets accept connections on any/all local addresses. This may be a problem on multi-homed hosts. To bind only to one address, use the system property h2.bindAddress. This setting is used for both regular server sockets and for TLS server sockets. IPv4 and IPv6 address formats are supported.

Pluggable File System

This database supports a pluggable file system API. The file system implementation is selected using a file name prefix. Internally, the interfaces are very similar to the Java 7 NIO2 API. The following file systems are included:

• file: the default file system that uses FileChannel.
• zip: read-only zip-file based file system. Format: zip:~/zipFileName!/fileName.
• split: file system that splits files in 1 GB files (stackable with other file systems).
• nioMapped: file system that uses memory mapped files (faster in some operating systems). Please note that there currently is a file size limitation of 2 GB when using this file system. To work around this limitation, combine it with the split file system: split:nioMapped:~/test.
• async: experimental file system that uses AsynchronousFileChannel instead of FileChannel (faster in some operating systems).
• memFS: in-memory file system (slower than mem; experimental; mainly used for testing the database engine itself).
• memLZF: compressing in-memory file system (slower than memFS but uses less memory; experimental; mainly used for testing the database engine itself).
• nioMemFS: stores data outside of the VM's heap - useful for large memory DBs without incurring GC costs.
• nioMemLZF: stores compressed data outside of the VM's heap - useful for large memory DBs without incurring GC costs. Use "nioMemLZF:12:" to tweak the % of blocks that are stored uncompressed. If you size this to your working set correctly, compressed storage is roughly the same performance as uncompressed. The default value is 1%.

As an example, to use the async: file system use the following database URL: jdbc:h2:async:~/test.

To register a new file system, extend the classes org.h2.store.fs.FilePath, FileBase, and call the method FilePath.register before using it.

For input streams (but not for random access files), URLs may be used in addition to the registered file systems. Example: jar:file:///c:/temp/example.zip!/org/example/nested.csv. To read a stream from the classpath, use the prefix classpath:, as in classpath:/org/h2/samples/newsfeed.sql.

Split File System

The file system prefix split: is used to split logical files into multiple physical files, for example so that a database can get larger than the maximum file system size of the operating system. If the logical file is larger than the maximum file size, then the file is split as follows:

• <fileName> (first block, is always created)
• <fileName>.1.part (second block)

More physical files (*.2.part, *.3.part) are automatically created / deleted if needed. The maximum physical file size of a block is 2^30 bytes, which is also called 1 GiB or 1 GB. However this can be changed if required, by specifying the block size in the file name. The file name format is: split:<x>:<fileName> where the file size per block is 2^x. For 1 MiB block sizes, use x = 20 (because 2^20 is 1 MiB). The following file name means the logical file is split into 1 MiB blocks: split:20:~/test.h2.db. An example database URL for this case is jdbc:h2:split:20:~/test.

Java Objects Serialization

Java objects serialization is enabled by default for columns of type OTHER, using standard Java serialization/deserialization semantics.

To disable this feature set the system property h2.serializeJavaObject=false (default: true).

Serialization and deserialization of java objects is customizable both at system level and at database level providing a JavaObjectSerializer implementation:

• At system level set the system property h2.javaObjectSerializer with the Fully Qualified Name of the JavaObjectSerializer interface implementation. It will be used over the entire JVM session to (de)serialize java objects being stored in column of type OTHER. Example h2.javaObjectSerializer=com.acme.SerializerClassName.
• At database level execute the SQL statement SET JAVA_OBJECT_SERIALIZER 'com.acme.SerializerClassName' or append ;JAVA_OBJECT_SERIALIZER='com.acme.SerializerClassName' to the database URL: jdbc:h2:~/test;JAVA_OBJECT_SERIALIZER='com.acme.SerializerClassName'.

  Please note that this SQL statement can only be executed before any tables are defined.

Limits and Limitations

This database has the following known limitations:

• Database file size limit: 4 TB (using the default page size of 2 KB) or higher (when using a larger page size). This limit is including CLOB and BLOB data.
• The maximum file size for FAT or FAT32 file systems is 4 GB. That means when using FAT or FAT32, the limit is 4 GB for the data. This is the limitation of the file system. The database does provide a workaround for this problem, it is to use the file name prefix split:. In that case files are split into files of 1 GB by default. An example database URL is: jdbc:h2:split:~/test.
• The maximum number of rows per table is 2^64.
• The maximum number of open transactions is 65535.
• The maximum number of columns in a table or expressions in a SELECT statement is 16384. The actual possible number can be smaller if their definitions are too long.
• The maximum length of an identifier (table name, column name, and so on) is 256 characters.
• The maximum length of CHARACTER, CHARACTER VARYING and VARCHAR_IGNORECASE values and columns is 1_000_000_000 characters.
• The maximum length of BINARY, BINARY VARYING, JAVA_OBJECT, GEOMETRY, and JSON values and columns is 1_000_000_000 bytes.
• The maximum precision of NUMERIC and DECFLOAT values and columns is 100000.
• The maximum length of an ENUM value is 1048576 characters, the maximum number of ENUM values is 65536.
• The maximum cardinality of an ARRAY value or column is 65536.
• The maximum degree of a ROW value or column is 16384.
• The maximum index of parameter is 100000.
• Main memory requirements: The larger the database, the more main memory is required.
• Limit on the complexity of SQL statements. Very complex expressions may result in a stack overflow exception.
• There is no limit for the following entities, except the memory and storage capacity: maximum number of tables, indexes, triggers, and other database objects; maximum statement length, tables per statement; maximum rows per query; maximum indexes per table, lob columns per table, and so on; maximum row length, index row length, select row length.
• Querying from the metadata tables is slow if there are many tables (thousands).
• For other limitations on data types, see the data type documentation of this database.

Glossary and Links

Term	Description
AES-128	A block encryption algorithm. See also: Wikipedia: Advanced Encryption Standard
Birthday Paradox	Describes the higher than expected probability that two persons in a room have the same birthday. Also valid for randomly generated UUIDs. See also: Wikipedia: Birthday problem
Digest	Protocol to protect a password (but not to protect data). See also: RFC 2617: HTTP Digest Access Authentication
HTTPS	A protocol to provide security to HTTP connections. See also: RFC 2818: HTTP Over TLS
Modes of Operation	Wikipedia: Block cipher mode of operation
Salt	Random number to increase the security of passwords. See also: Wikipedia: Key derivation function
SHA-256	A cryptographic one-way hash function. See also: Wikipedia: Secure Hash Algorithms
SQL Injection	A security vulnerability where an application embeds SQL statements or expressions in user input. See also: Wikipedia: SQL injection
Watermark Attack	Security problem of certain encryption programs where the existence of certain data can be proven without decrypting. For more information, search in the internet for 'watermark attack cryptoloop'
SSL/TLS	Secure Sockets Layer / Transport Layer Security. See also: Java Secure Socket Extension (JSSE)