H2 Database に向く Web アプリケーション

H2 Database のロック機構は、テーブルロックしかなく、かつ EXCLUSIVE と SHARED の2種類しかないという単純なものです。

  • EXCLUSIVE ロックは EXCLUSIVE ロックとも、SHARED ロックとも競合する。SHARED ロックどうしは競合しない。
  • insert, update, delete といった更新系の処理は、EXCLUSIVE ロックを要求する。
  • select は、SHARED ロックを要求する。ただし select for update は EXCLUSIVE ロックを要求する。

上記から考えると、insert, update, delete を実行するトランザクションが走っている間は、select は待たされることになります。
H2 Database のドキュメントにも記載されていますが、これは同時実行並列性が低いといえます。(代わりに高速に動作するという長所を得ている。)

この特性を考慮すると、H2 Database を利用可能なWebアプリケーションの特性が見えてきます。

ようなWebアプリケーションで利用するにおいては、注意が必要です。
少数の更新系トランザクションによってテーブルがロックされ、データの参照すら行えないという事象が多発する可能性があります。

逆に軽量高速なので、上記に該当しない場合には、向いていると思います。(ただしデータ量次第なので注意が必要)

またオンメモリで動作させることもできるので、メインのデータベースではなく、サブのデータベースとして使うということも考えられます。
ただしこれは、Web アプリケーションを Java で作成する場合に限った利用方法です。

H2 Database の明示的ロック

H2 Database には、行レベルロックはない。テーブルレベルロックのみ。
並列性は低くなるものの、処理が高速になるので、テーブルレベルロックのみにしているようです。

別途、MVCC (Multi-Version Concurrency Control) という仕組みが開発されているようですが、まだテストが十分でないとのことです。

SQL テーブルレベル
SELECT FOR UPDATE EXCLUSIVE
UPDATE, INSERT, DELETE EXCLUSIVE

ロックは SHARED と EXCLUSIVE の2種類のみ。
EXCLUSIVE LOCK を獲得するとリリースされるまで、ロックを要求する他のトランザクションは待たされます。

http://www.h2database.com/html/advanced.html#transaction_isolation

PostgreSQLの明示的ロック

SQL テーブルレベル 行レベル
SELECT FOR UPDATE ROW SHARE 行レベルロック獲得
UPDATE, INSERT, DELETE ROW EXCLUSIVE 行レベルロック獲得

ROW SHAREとROW EXCLUSIVE は競合関係にないので、テーブルレベルでは上記SQL文は競合しない。

行レベルではもちろん競合する。

データベースの ISOLATION レベルサポート状況

必要があったので、少しデータベースの ISOLATION レベルのサポート状況を調べました。

  • PostgreSQL
    • READ COMMITTED(default)
    • SERIALIZABLE
  • H2
    • READ UNCOMMITTED
    • READ COMMITTED(default)
    • SERIALIZABLE
  • MySQL InnoDB
    • READ UNCOMMITTED
    • READ COMMITTED
    • REPEATABLE READ(default)
    • SERIALIZABLE

PostgreSQL は数年前から変わっていないようです。

Intermediate Boundary Events in BPMN 2.0

BPMN 2.0 の仕様策定が進んでいます。昨年夏に Beta1 が公開されそこからまだ進展していないのが気がかりですが、今年はそれに対応した製品の開発が加速するという話も聞きます。

さて肝心の内容ですが、BPMN 1.2 からいくつかのアイコンが追加されています。私が注目したのは、タスクやサブプロセスの境界線上に置く中間イベントのパターンが大きく2種類に分かれたことです。

境界線上の中間イベントとは、イベントの条件が整うと、例外フローに移行することを表すものです。たとえばタイマー中間イベントの場合は、指定の時刻が来ると例外フローに移行することを表します。

BPMN 2.0 では、例外フローに移行する際、対象のタスクやサブプロセスをキャンセルするかどうか区別できるようになりました。下の図がタイマー中間イベントにおける2種類のアイコンを表したものですが、前者がキャンセルするタイプ、後者がキャンセルしないタイプです。(図が手書き風ですが、実際に BPMN 2.0 beta1 の仕様書内のものをコピーしたものです)

たとえば締め切りの1週間前に警告を行い、締め切りが来たら例外フローに移行するということが容易に表現できるようになります。

更に BPMN 2.0 を理解していきたいと思います。

「孤独死」は社会にとって大きな問題ではないが、NHKの「無縁社会」

筆者の主張するところに、大きく異論はない。死に方は自由だ。社会の問題でもない。

しかし筆者のNHKの「無縁社会」に関する意見に、私は賛成しない。

生と死は表裏一体でどう死ぬかを考えることは、どう生きるかを考えることに等しいと私は考えている。

したがって孤独に死ぬということは、死ぬ前は孤独に生きていたということだ。

本当に孤独に生きることを望んでいるのか?
そんなふうに死ぬように生きることを、あなたは望んでいるのか?

無縁社会」はその1点を問いかけているにすぎないと私は理解している。

小野小町が自分が死んだら遺骸を飢えた犬の餌にしてやれと歌を詠んだのは、小野小町が孤独に生きていなかったからだと思う。
本当に社会と無縁で孤独でそう望んでいるなら、勝手に路上で死ねばよい。

しかし社会や政府が、この問題に何か取り組まなくてはならないとは考えない。
これは1人1人が考えるべき個人の問題だ。