http://www.h2database.com/html/frame.html

 

最近一個桌面的程序需要使用嵌入式數(shù)據(jù)庫，選擇了很多不同的嵌入式數(shù)據(jù),最終選擇了H2，性能是一個很重要的原因，下圖是h2提供的Performance的比較圖

http://www.h2database.com/html/images/performance.png

 

h2是Thomas Mueller提供的一個開源的、純java實現(xiàn)的關系數(shù)據(jù)庫，在google上面有討論組h2-database@googlegroups.com，Thomas Mueller也非常熱情，回答問題非常及時。

 

下面說下我最終選擇h2的原因：

（1）性能、小巧

（2）同時支持網(wǎng)絡版和嵌入式版本，另外還提供了內存版

（3）有比較好的兼容性，支持相當標準的sql標準（實際上也不存在一個數(shù)據(jù)庫能夠100%符合標準）

（4）提供了非常友好的基于web的數(shù)據(jù)庫管理界面

（5）支持hibernate



補充：
支持的事務隔離級別：

Transaction Isolation

This database supports the following transaction isolation levels:

  • Serializable
    This is the default level.
    To enable, execute the SQL statement 'SET LOCK_MODE 0'
    or append ;LOCK_MODE=1 to the database URL: jdbc:h2:~/test;LOCK_MODE=1
  • Read Committed
    Read locks are released immediately. Higher concurrency is possible when using this level.
    This is the isolation level used for many database systems.
    To enable, execute the SQL statement 'SET LOCK_MODE 0'
    or append ;LOCK_MODE=3 to the database URL: jdbc:h2:~/test;LOCK_MODE=3
  • Read Uncommitted
    This level means that transaction isolation is disabled.
    To enable, execute the SQL statement 'SET LOCK_MODE 0'
    or append ;LOCK_MODE=0 to the database URL: jdbc:h2:~/test;LOCK_MODE=0

When using the isolation level 'serializable', dirty reads, non-repeatable reads, and phantom reads are prohibited.

  • 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

Table Level Locking

The database allows multiple concurrent connections to the same database. To make sure all connections only see consistent data, table level locking is used. 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.