<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!--
Copyright 2004-2008 H2 Group. Multiple-Licensed under the H2 License, Version 1.0,
and under the Eclipse Public License, Version 1.0
(http://h2database.com/html/license.html).
Initial Developer: H2 Group
-->
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head><meta http-equiv="Content-Type" content="text/html;charset=utf-8" /><title>
Advanced Topics
</title><link rel="stylesheet" type="text/css" href="stylesheet.css" />
<!-- [search] { -->
<script type="text/javascript" src="navigation.js"></script>
</head><body onload="frameMe();">
<table class="content"><tr class="content"><td class="content"><div class="contentDiv">
<!-- } -->
<h1>Advanced Topics</h1>
<a href="#result_sets">
Result Sets</a><br />
<a href="#large_objects">
Large Objects</a><br />
<a href="#linked_tables">
Linked Tables</a><br />
<a href="#transaction_isolation">
Transaction Isolation</a><br />
<a href="#mvcc">
Multi-Version Concurrency Control (MVCC)</a><br />
<a href="#clustering">
Clustering / High Availability</a><br />
<a href="#two_phase_commit">
Two Phase Commit</a><br />
<a href="#compatibility">
Compatibility</a><br />
<a href="#standards_compliance">
Standards Compliance</a><br />
<a href="#windows_service">
Run as Windows Service</a><br />
<a href="#odbc_driver">
ODBC Driver</a><br />
<a href="#microsoft_dot_net">
Using H2 in Microsoft .NET</a><br />
<a href="#acid">
ACID</a><br />
<a href="#durability_problems">
Durability Problems</a><br />
<a href="#using_recover_tool">
Using the Recover Tool</a><br />
<a href="#file_locking_protocols">
File Locking Protocols</a><br />
<a href="#sql_injection">
Protection against SQL Injection</a><br />
<a href="#restricting_classes">
Restricting Class Loading and Usage</a><br />
<a href="#security_protocols">
Security Protocols</a><br />
<a href="#ssl_tls_connections">
SSL/TLS Connections</a><br />
<a href="#uuid">
Universally Unique Identifiers (UUID)</a><br />
<a href="#system_properties">
Settings Read from System Properties</a><br />
<a href="#server_bind_address">
Setting the Server Bind Address</a><br />
<a href="#limitations">
Limitations</a><br />
<a href="#glossary_links">
Glossary and Links</a><br />
<br /><a name="result_sets"></a>
<h2>Result Sets</h2>
<h3>Limiting the Number of Rows</h3>
<p>
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 LIMIT in a query (example: SELECT * FROM TEST LIMIT 100),
or by using Statement.setMaxRows(max).
</p>
<h3>Large Result Sets and External Sorting</h3>
<p>
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.
</p>
<br /><a name="large_objects"></a>
<h2>Large Objects</h2>
<h3>Storing and Reading Large Objects</h3>
<p>
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.
If the client/server mode is used, the BLOB and CLOB data is fully read into memory when
accessed. In this case, the size of a BLOB or CLOB is limited by the memory.
</p>
<br /><a name="linked_tables"></a>
<h2>Linked Tables</h2>
<p>
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:
</p>
<pre>
CREATE LINKED TABLE LINK('org.postgresql.Driver', 'jdbc:postgresql:test', 'sa', 'sa', 'TEST');
</pre>
<p>
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 <code>SELECT * FROM LINK WHERE ID=1</code>,
then the following query is run against the PostgreSQL database: <code>SELECT * FROM TEST WHERE ID=?</code>.
The same happens for insert and update statements. Only simple statements are executed against the
target database, that means no joins. Prepared statements are used where possible.
</p>
<p>
To view the statements that are executed against the target table, set the trace level to 3.
</p>
<p>
There is a restriction when inserting data to this table: When inserting or updating rows into the table,
NULL and values that are not set in the insert statement are both inserted as NULL.
This may not have the desired effect if a default value in the target table is other than NULL.
</p>
<p>
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 to false.
</p>
<p>
The CREATE LINKED TABLE statement supports an optional schema name parameter.
See the grammar for details.
</p>
<br /><a name="transaction_isolation"></a>
<h2>Transaction Isolation</h2>
<p>
This database supports the following transaction isolation levels:
</p>
<ul>
<li><b>Read Committed</b><br />
This is the default level.
Read locks are released immediately.
Higher concurrency is possible when using this level.<br />
To enable, execute the SQL statement 'SET LOCK_MODE 3'<br />
or append ;LOCK_MODE=3 to the database URL: jdbc:h2:~/test;LOCK_MODE=3
</li><li>
<b>Serializable</b><br />
To enable, execute the SQL statement 'SET LOCK_MODE 1'<br />
or append ;LOCK_MODE=1 to the database URL: jdbc:h2:~/test;LOCK_MODE=1
</li><li><b>Read Uncommitted</b><br />
This level means that transaction isolation is disabled.<br />
To enable, execute the SQL statement 'SET LOCK_MODE 0'<br />
or append ;LOCK_MODE=0 to the database URL: jdbc:h2:~/test;LOCK_MODE=0
</li>
</ul>
<p>
When using the isolation level 'serializable', dirty reads, non-repeatable reads, and phantom reads are prohibited.
</p>
<ul>
<li><b>Dirty Reads</b><br />
Means a connection can read uncommitted changes made by another connection.<br />
Possible with: read uncommitted
</li><li><b>Non-Repeatable Reads</b><br />
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.<br />
Possible with: read uncommitted, read committed
</li><li><b>Phantom Reads</b><br />
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.<br />
Possible with: read uncommitted, read committed
</li>
</ul>
<h3>Table Level Locking</h3>
<p>
The database allows multiple concurrent connections to the same database.
To make sure all connections only see consistent data, table level locking is used by default.
This mechanism does not allow high concurrency, but is very fast.
Shared locks and exclusive locks are supported.
Before reading from a table, the database tries to add a shared lock to the table
(this is only possible if there is no exclusive lock on the object by another connection).
If the shared lock is added successfully, the table can be read. It is allowed that
other connections also have a shared lock on the same object. If a connection wants
to write to a table (update or delete a row), an exclusive lock is required. To get the
exclusive lock, other connection must not have any locks on the object. After the
connection commits, all locks are released.
This database keeps all locks in memory.
</p>
<h3>Lock Timeout</h3>
<p>
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.
</p>
<br /><a name="mvcc"></a>
<h2>Multi-Version Concurrency Control (MVCC)</h2>
<p>
The MVCC feature allows higher concurrency than using (table level or row level) locks.
When using MVCC in this database, delete, insert and update operations will only issue a
shared lock on the table. An exclusive lock is still used when adding or removing columns,
when dropping the table, and when using SELECT ... FOR UPDATE. 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 update the same row, this
database fails fast: a concurrent update exception is thrown.
</p>
<p>
To use the MVCC feature, append MVCC=TRUE to the database URL:
</p>
<pre>
jdbc:h2:~/test;MVCC=TRUE
</pre>
<p>
MVCC can not be used at the same time as MULTI_THREADED.
The MVCC feature is not fully tested yet.
</p>
<br /><a name="clustering"></a>
<h2>Clustering / High Availability</h2>
<p>
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.
</p><p>
Clustering can only be used in the server mode (the embedded mode does not support clustering).
It is possible to restore the cluster without stopping the server, however it is critical that no other
application is changing the data in the first database while the second database is restored, so
restoring the cluster is currently a manual process.
</p><p>
To initialize the cluster, use the following steps:
</p>
<ul>
<li>Create a database
</li><li>Use the CreateCluster tool to copy the database to another location and initialize the clustering.
Afterwards, you have two databases containing the same data.
</li><li>Start two servers (one for each copy of the database)
</li><li>You are now ready to connect to the databases with the client application(s)
</li></ul>
<h3>Using the CreateCluster Tool</h3>
<p>
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.
</p>
<ul>
<li>Create two directories: server1 and server2.
Each directory will simulate a directory on a computer.
</li><li>Start a TCP server pointing to the first directory.
You can do this using the command line:
<pre>
java org.h2.tools.Server
-tcp -tcpPort 9101
-baseDir server1
</pre>
</li><li>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:
<pre>
java org.h2.tools.Server
-tcp -tcpPort 9102
-baseDir server2
</pre>
</li><li>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:
<pre>
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
</pre>
</li><li>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
</li><li>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.
</li><li>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.
</li></ul>
<h3>Clustering Algorithm and Limitations</h3>
<p>
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: 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, or MERGE). However, they can be used
in read-only statements and the result can then be used for modifying statements.
</p>
<br /><a name="two_phase_commit"></a>
<h2>Two Phase Commit</h2>
<p>
The two phase commit protocol is supported. 2-phase-commit works as follows:
</p>
<ul>
<li>Autocommit needs to be switched off
</li><li>A transaction is started, for example by inserting a row
</li><li>The transaction is marked 'prepared' by executing the SQL statement
<code>PREPARE COMMIT transactionName</code>
</li><li>The transaction can now be committed or rolled back
</li><li>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'
</li><li>When re-connecting to the database, the in-doubt transactions can be listed
with <code>SELECT * FROM INFORMATION_SCHEMA.IN_DOUBT</code>
</li><li>Each transaction in this list must now be committed or rolled back by executing
<code>COMMIT TRANSACTION transactionName</code> or
<code>ROLLBACK TRANSACTION transactionName</code>
</li><li>The database needs to be closed and re-opened to apply the changes
</li></ul>
<br /><a name="compatibility"></a>
<h2>Compatibility</h2>
<p>
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.
</p>
<h3>Transaction Commit when Autocommit is On</h3>
<p>
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.
</p>
<h3>Keywords / Reserved Words</h3>
<p>
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 list is currently:
</p><p>
CURRENT_TIMESTAMP, CURRENT_TIME, CURRENT_DATE, CROSS, DISTINCT, EXCEPT, EXISTS, FROM,
FOR, FALSE, FULL, GROUP, HAVING, INNER, INTERSECT, IS, JOIN, LIKE, MINUS, NATURAL, NOT, NULL,
ON, ORDER, PRIMARY, ROWNUM, SELECT, SYSDATE, SYSTIME, SYSTIMESTAMP, TODAY, TRUE, UNION, WHERE
</p><p>
Certain words of this list are keywords because they are functions that can be used without '()' for compatibility,
for example CURRENT_TIMESTAMP.
</p>
<br /><a name="standards_compliance"></a>
<h2>Standards Compliance</h2>
<p>
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.
</p>
<br /><a name="windows_service"></a>
<h2>Run as Windows Service</h2>
<p>
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.
(<a href="http://wrapper.tanukisoftware.org">http://wrapper.tanukisoftware.org</a>)
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.
</p>
<h3>Install the Service</h3>
<p>
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.
</p>
<h3>Start the Service</h3>
<p>
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.
</p>
<h3>Connect to the H2 Console</h3>
<p>
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.
</p>
<h3>Stop the Service</h3>
<p>
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.
</p>
<h3>Uninstall the Service</h3>
<p>
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.
</p>
<br /><a name="odbc_driver"></a>
<h2>ODBC Driver</h2>
<p>
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.
</p>
<p>
To use the PostgreSQL ODBC driver on 64 bit versions of Windows,
first run <code>c:/windows/syswow64/odbcad32.exe</code>.
At this point you set up your DSN just like you would on any other system.
See also:
<a href="http://archives.postgresql.org/pgsql-odbc/2005-09/msg00125.php">Re: ODBC Driver on Windows 64 bit</a>
</p>
<h3>ODBC Installation</h3>
<p>
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
<a href="http://www.postgresql.org/ftp/odbc/versions/msi">http://www.postgresql.org/ftp/odbc/versions/msi</a>.
</p>
<h3>Starting the Server</h3>
<p>
After installing the ODBC driver, start the H2 Server using the command line:
</p>
<pre>
java -cp h2*.jar org.h2.tools.Server
</pre>
<p>
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:
</p>
<pre>
java -cp h2*.jar org.h2.tools.Server -baseDir ~
</pre>
<p>
The PG server can be started and stopped from within a Java application as follows:
</p>
<pre>
Server server = Server.createPgServer(new String[]{"-baseDir", "~"});
server.start();
...
server.stop();
</pre>
<p>
By default, only connections from localhost are allowed. To allow remote connections, use
<code>-pgAllowOthers true</code> when starting the server.
</p>
<h3>ODBC Configuration</h3>
<p>
After installing the driver, a new Data Source must be added. In Windows,
run <code>odbcad32.exe</code> 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:
</p>
<table>
<tr><th>Property</th><th>Example</th><th>Remarks</th></tr>
<tr><td>Data Source</td><td>H2 Test</td><td>The name of the ODBC Data Source</td></tr>
<tr><td>Database</td><td>test</td>
<td>
The database name. Only simple names are supported at this time; <br />
relative or absolute path are not supported in the database name. <br />
By default, the database is stored in the current working directory <br />
where the Server is started except when the -baseDir setting is used. <br />
The name must be at least 3 characters.
</td></tr>
<tr><td>Server</td><td>localhost</td><td>The server name or IP address.<br />By default, only remote connections are allowed</td></tr>
<tr><td>User Name</td><td>sa</td><td>The database user name.</td></tr>
<tr><td>SSL Mode</td><td>disabled</td><td>At this time, SSL is not supported.</td></tr>
<tr><td>Port</td><td>5435</td><td>The port where the PG Server is listening.</td></tr>
<tr><td>Password</td><td>sa</td><td>The database password.</td></tr>
</table>
<p>
To improve performance, please enable 'server side prepare' under Options / Datasource / Page 2 / Server side prepare.
</p>
<p>
Afterwards, you may use this data source.
</p>
<h3>PG Protocol Support Limitations</h3>
<p>
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.
</p>
<p>
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.
</p>
<h3>Security Considerations</h3>
<p>
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.
</p>
<br /><a name="microsoft_dot_net"></a>
<h2>Using H2 in Microsoft .NET</h2>
<p>
The database can be used from Microsoft .NET even without using Java, by using IKVM.NET.
You can access a H2 database on .NET using the JDBC API, or using the ADO.NET interface.
</p>
<h3>Using the ADO.NET API on .NET</h3>
<p>
An implementation of the ADO.NET interface is available in the open source project
<a href="http://code.google.com/p/h2sharp">H2Sharp</a>.
</p>
<h3>Using the JDBC API on .NET</h3>
<ul><li>Install the .NET Framework from <a href="http://www.microsoft.com">Microsoft</a>.
Mono has not yet been tested.
</li><li>Install <a href="http://www.ikvm.net">IKVM.NET</a>.
</li><li>Copy the h2*.jar file to ikvm/bin
</li><li>Run the H2 Console using:
<code>ikvm -jar h2*.jar</code>
</li><li>Convert the H2 Console to an .exe file using:
<code>ikvmc -target:winexe h2*.jar</code>.
You may ignore the warnings.
</li><li>Create a .dll file using (change the version accordingly):
<code>ikvmc.exe -target:library -version:1.0.69.0 h2*.jar</code>
</li></ul>
<p>
If you want your C# application use H2, you need to add the h2.dll and the
IKVM.OpenJDK.ClassLibrary.dll to your C# solution. Here some sample code:
</p>
<pre>
using System;
using java.sql;
class Test
{
static public void Main()
{
org.h2.Driver.load();
Connection conn = DriverManager.getConnection("jdbc:h2:~/test", "sa", "sa");
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery("SELECT 'Hello World'");
while (rs.next())
{
Console.WriteLine(rs.getString(1));
}
}
}
</pre>
<br /><a name="acid"></a>
<h2>ACID</h2>
<p>
In the database world, ACID stands for:
</p>
<ul>
<li>Atomicity: Transactions must be atomic, meaning either all tasks are performed or none.
</li><li>Consistency: All operations must comply with the defined constraints.
</li><li>Isolation: Transactions must be isolated from each other.
</li><li>Durability: Committed transaction will not be lost.
</li></ul>
<h3>Atomicity</h3>
<p>
Transactions in this database are always atomic.
</p>
<h3>Consistency</h3>
<p>
This database is always in a consistent state.
Referential integrity rules are always enforced.
</p>
<h3>Isolation</h3>
<p>
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 'serializable', 'read committed', and 'read uncommitted'.
</p>
<h3>Durability</h3>
<p>
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.
</p>
<br /><a name="durability_problems"></a>
<h2>Durability Problems</h2>
<p>
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.
</p>
<h3>Ways to (Not) Achieve Durability</h3>
<p>
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":
</p>
<ul>
<li>rwd: Every update to the file's content is written synchronously to the underlying storage device.
</li><li>rws: In addition to rwd, every update to the metadata is written synchronously.</li>
</ul>
<p>
This feature is used by Derby.
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.
</p>
<p>
Calling fsync flushes the buffers. There are two ways to do that in Java:
</p>
<ul>
<li>FileDescriptor.sync(). The documentation says that this forces all system buffers to synchronize with the underlying device.
Sync is supposed to return after all in-memory modified copies of buffers associated with this FileDescriptor
have been written to the physical medium.
</li><li>FileChannel.force() (since JDK 1.4). This method is supposed to force any updates to this channel's file
to be written to the storage device that contains it.
</li></ul>
<p>
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
<a href="http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252">Your Hard Drive Lies to You</a>.
In Mac OS X, fsync does not flush hard drive buffers. See
<a href="http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html">Bad fsync?</a>.
So the situation is confusing, and tests prove there is a problem.
</p>
<p>
Trying to flush hard drive buffers 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.
</p>
<p>
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.
</p>
<h3>Running the Durability Test</h3>
<p>
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.
</p>
<br /><a name="using_recover_tool"></a>
<h2>Using the Recover Tool</h2>
<p>
The recover tool can be used to extract the contents of a data file, even if the database is corrupted.
At this time, it does not extract the content of the log file or large objects (CLOB or BLOB).
To run the tool, type on the command line:
</p>
<pre>
java org.h2.tools.Recover
</pre>
<p>
For each database in the current directory, a text file will be created.
This file contains raw insert statement (for the data) and data definition (DDL) statement to recreate
the schema of the database. This file cannot be executed directly, as the raw insert statements
don't have the correct table names, so the file needs to be pre-processed manually before executing.
</p>
<br /><a name="file_locking_protocols"></a>
<h2>File Locking Protocols</h2>
<p>
Whenever a database is opened, a lock file is created to signal other processes
that the database is in use. If database is closed, or if the process that opened
the database terminates, this lock file is deleted.
</p><p>
In special cases (if the process did not terminate normally, for example because
there was a blackout), 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'.
</p>
<h3>File Locking Method 'File'</h3>
<p>
The default method for database file locking is the 'File Method'. The algorithm is:
</p>
<ul>
<li>When the lock file does not exist, it is created (using the atomic operation File.createNewFile).
Then, the process waits a little bit (20ms) and checks the file again. If the file was changed
during this time, the operation is aborted. This protects against a race condition
when a process deletes the lock file just after one create it, and a third process creates
the file again. It does not occur if there are only two writers.
</li><li>
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.
</li><li>
If the lock file exists, and it was modified in the 20 ms, the process waits for some time (up to 10 times).
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.
</li></ul>
<p>
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.
</p>
<h3>File Locking Method 'Socket'</h3>
<p>
There is a second locking mechanism implemented, but disabled by default.
The algorithm is:
</p>
<ul>
<li>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.
</li><li>If the lock file exists, and the lock method is 'file', then the software switches
to the 'file' method.
</li><li>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 blackout, or abnormal termination of the virtual machine),
then the port was released. The new process deletes the lock file and starts again.
</li></ul>
<p>
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.
</p>
<br /><a name="sql_injection"></a>
<h2>Protection against SQL Injection</h2>
<h3>What is SQL Injection</h3>
<p>
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:
</p>
<pre>
String sql = "SELECT * FROM USERS WHERE PASSWORD='"+pwd+"'";
ResultSet rs = conn.createStatement().executeQuery(sql);
</pre>
<p>
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:
</p>
<pre>
SELECT * FROM USERS WHERE PASSWORD='' OR ''='';
</pre>
<p>
Which is always true no matter what the password stored in the database is.
For more information about SQL Injection, see Glossary and Links.
</p>
<h3>Disabling Literals</h3>
<p>
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 PreparedStatement:
</p>
<pre>
String sql = "SELECT * FROM USERS WHERE PASSWORD=?";
PreparedStatement prep = conn.prepareStatement(sql);
prep.setString(1, pwd);
ResultSet rs = prep.executeQuery();
</pre>
<p>
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:
</p>
<pre>
SET ALLOW_LITERALS NONE;
</pre>
<p>
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 PreparedStatements 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.
</p>
<h3>Using Constants</h3>
<p>
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:
</p>
<pre>
CREATE SCHEMA CONST AUTHORIZATION SA;
CREATE CONSTANT CONST.ACTIVE VALUE 'Active';
CREATE CONSTANT CONST.INACTIVE VALUE 'Inactive';
SELECT * FROM USERS WHERE TYPE=CONST.ACTIVE;
</pre>
<p>
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.
</p>
<h3>Using the ZERO() Function</h3>
<p>
It is not required to create a constant for the number 0 as there is already a built-in function ZERO():
</p>
<pre>
SELECT * FROM USERS WHERE LENGTH(PASSWORD)=ZERO();
</pre>
<br /><a name="restricting_classes"></a>
<h2>Restricting Class Loading and Usage</h2>
<p>
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:
</p>
<pre>
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');
</pre>
<p>
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:
</p>
<pre>
java -Dh2.allowedClasses=java.lang.Math,com.acme.*
</pre>
<p>
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.
</p>
<br /><a name="security_protocols"></a>
<h2>Security Protocols</h2>
<p>
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.
</p>
<h3>User Password Encryption</h3>
<p>
When a user tries to connect to a database, the combination of
user name, @, and password hashed using SHA-256, and this hash value
is transmitted to the database.
This step does not try to an attacker from re-using 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.
</p><p>
When a new database or user is created, a new cryptographically secure
random salt value is generated. The size of the salt is 64 bit.
Using the random salt reduces the risk of an attacker pre-calculating hash values
for many different (commonly used) passwords.
</p><p>
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 calculated 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 remotely, then the iteration count is not required at all.
</p>
<h3>File Encryption</h3>
<p>
The database files can be encrypted using two different algorithms: AES-128 and
XTEA (using 32 rounds). The reasons for supporting XTEA is performance
(XTEA is about twice as fast as AES) and to have an alternative algorithm if
AES is suddenly broken.
</p><p>
When a user tries to connect to an encrypted database, the combination of the word
'file', @, and the file password is hashed using SHA-256. This hash value is
transmitted to the server.
</p><p>
When a new database file is created, a new cryptographically secure
random salt value is generated. The size of the salt is 64 bit.
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.
</p><p>
The resulting hash value is used as the key for the block cipher algorithm
(AES-128 or XTEA with 32 rounds). 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.
</p><p>
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 or XTEA algorithm.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
File encryption slows down the performance of the database engine. Compared to unencrypted mode,
database operations take about 2.2 times longer when using XTEA, and 2.5 times longer using AES (embedded mode).
</p>
<h3>Wrong Password Delay</h3>
<p>
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 (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.
</p>
<h3>HTTPS Connections</h3>
<p>
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.
</p>
<br /><a name="ssl_tls_connections"></a>
<h2>SSL/TLS Connections</h2>
<p>
Remote SSL/TLS connections are supported using the Java Secure Socket Extension
(SSLServerSocket / SSLSocket). By default, anonymous SSL is enabled.
The default cipher suite is <code>SSL_DH_anon_WITH_RC4_128_MD5</code>.
</p>
<p>
To use your own keystore, set the system properties <code>javax.net.ssl.keyStore</code> and
<code>javax.net.ssl.keyStorePassword</code> before starting the H2 server and client.
See also <a href="http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores">
Customizing the Default Key and Trust Stores, Store Types, and Store Passwords</a>
for more information.
</p>
<p>
To disable anonymous SSL, set the system property <code>h2.enableAnonymousSSL</code> to false.
</p>
<br /><a name="uuid"></a>
<h2>Universally Unique Identifiers (UUID)</h2>
<p>
This database supports the 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'.
Standardized randomly generated UUIDs 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().
Here is a small program to estimate the probability of having two identical UUIDs
after generating a number of values:
</p>
<pre>
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));
String ps = String.valueOf(1+p).substring(1);
System.out.println("2^"+i+"="+(1L<<i)+" probability: 0"+ps);
}
</pre>
<p>
Some values are:
</p>
<pre>
2^36=68'719'476'736 probability: 0.000'000'000'000'000'4
2^41=2'199'023'255'552 probability: 0.000'000'000'000'4
2^46=70'368'744'177'664 probability: 0.000'000'000'4
</pre>
<p>
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.
</p>
<br /><a name="system_properties"></a>
<h2>Settings Read from System Properties</h2>
<p>
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:
</p>
<pre>
java -Dh2.serverCachedObjects=256 org.h2.tools.Server
</pre>
<p>
The current value of the settings can be read in the table
INFORMATION_SCHEMA.SETTINGS.
</p>
<p>
For a complete list of settings, see
<a href="../javadoc/org/h2/constant/SysProperties.html">SysProperties</a>.
</p>
<br /><a name="server_bind_address"></a>
<h2>Setting the Server Bind Address</h2>
<p>
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 SSL server sockets.
IPv4 and IPv6 address formats are supported.
</p>
<br /><a name="limitations"></a>
<h2>Limitations</h2>
<p>
This database has the following known limitations:
</p>
<ul>
<li>The maximum file size is currently 256 GB for the data, and 256 GB for the index.
This number is excluding BLOB and CLOB data:
Every CLOB or BLOB can be up to 256 GB as well.
</li><li>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, and this database does not provide a
workaround for this problem. The suggested solution is to use another file system.
</li><li>There is a limit on the complexity of SQL statements.
Statements of the following form will result in a stack overflow exception:
<pre>
SELECT * FROM DUAL WHERE X = 1
OR X = 2 OR X = 2 OR X = 2 OR X = 2 OR X = 2
-- repeat previous line 500 times --
</pre>
</li><li>There is no limit for the following entities, except the memory and storage capacity:
maximum identifier length, maximum number of tables, maximum number of columns,
maximum number of indexes, maximum number of parameters,
maximum number of triggers, and maximum number of other database objects.
</li><li>For limitations on data types, see the documentation of the respective Java data type
or the data type documentation of this database.
</li></ul>
<br /><a name="glossary_links"></a>
<h2>Glossary and Links</h2>
<table>
<tr>
<th>Term</th>
<th>Description</th>
</tr>
<tr>
<td>AES-128</td>
<td>A block encryption algorithm. See also: <a
href="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard">Wikipedia:
AES</a></td>
</tr>
<tr>
<td>Birthday Paradox</td>
<td>Describes the higher than expected probability that two
persons in a room have the same birthday. Also valid for randomly
generated UUIDs. See also: <a
href="http://en.wikipedia.org/wiki/Birthday_paradox">Wikipedia:
Birthday Paradox</a></td>
</tr>
<tr>
<td>Digest</td>
<td>Protocol to protect a password (but not to protect data).
See also: <a href="http://www.faqs.org/rfcs/rfc2617.html">RFC
2617: HTTP Digest Access Authentication</a></td>
</tr>
<tr>
<td>GCJ</td>
<td>Compiler for Java. <a href="http://gcc.gnu.org/java">GNU
Compiler for the Java</a> and <a
href="http://www.dobysoft.com/products/nativej">NativeJ
(commercial)</a></td>
</tr>
<tr>
<td>HTTPS</td>
<td>A protocol to provide security to HTTP connections. See
also: <a href="http://www.ietf.org/rfc/rfc2818.txt">RFC 2818:
HTTP Over TLS</a></td>
</tr>
<tr>
<td>Modes of Operation</td>
<td><a
href="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation">Wikipedia:
Block cipher modes of operation</a></td>
</tr>
<tr>
<td>Salt</td>
<td>Random number to increase the security of passwords. See
also: <a href="http://en.wikipedia.org/wiki/Key_derivation_function">Wikipedia:
Key derivation function</a></td>
</tr>
<tr>
<td>SHA-256</td>
<td>A cryptographic one-way hash function. See also: <a
href="http://en.wikipedia.org/wiki/SHA_family">Wikipedia: SHA
hash functions</a></td>
</tr>
<tr>
<td>SQL Injection</td>
<td>A security vulnerability where an application generates SQL
statements with embedded user input. See also: <a
href="http://en.wikipedia.org/wiki/SQL_injection">Wikipedia:
SQL Injection</a></td>
</tr>
<tr>
<td>Watermark Attack</td>
<td>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'</td>
</tr>
<tr>
<td>SSL/TLS</td>
<td>Secure Sockets Layer / Transport Layer Security. See also:
<a href="http://java.sun.com/products/jsse/">Java Secure Socket
Extension (JSSE)</a></td>
</tr>
<tr>
<td>XTEA</td>
<td>A block encryption algorithm. See also: <a
href="http://en.wikipedia.org/wiki/XTEA">Wikipedia: XTEA</a></td>
</tr>
</table>
<!-- [close] { --></div></td></tr></table><!-- } --><!-- analytics --></body></html>