【Java】H2 Database Engine【GCJ】
フリーのJava製データベースエンジン H2 について語れや。
・とっても速い、誰でも利用可能、ソース同梱
・Java製。LinuxならGCJでコンパイル可能。
・組込用にも、サーバ用にも、そしてクラスタモードも利用可能
・JDBC対応、一部ODBC対応。Webクライアント付属。
公式(要Javascript)
ttp://www.h2database.com/
■ 紹介ページ
使ってみようH2 Database Engine - 最強の呼び声もあるすごいヤツ
ttp://journal.mycom.co.jp/articles/2006/10/12/h2/
Hibernate - H2とExecute Queryで体験、定番の"Core"
ttp://journal.mycom.co.jp/articles/2006/10/21/hibernate/
■関連スレ
【Pure】HSQL database engine【Java】
ttp://pc8.2ch.net/test/read.cgi/db/1060970234/
【PureJava】 Derby 1 【OpenSource】
ttp://pc8.2ch.net/test/read.cgi/db/1128799341/ =FALSEの間違いじゃ？
あと、無指定でAutoCommitなのはJDBC仕様でしょ >>60
すみません、コピペ元のソースを間違えました
> あと、無指定でAutoCommitなのはJDBC仕様でしょ
そうなのか、知らなかった
どうでもいいですが、スレそのものの勢いは少ないけど、結構見ている方いるんですね。
Webインターフェースも ajax でオートコンプリートしたり、CSE や OsqlEdit(OsqlGrid) みたいに select してきた
結果表のマトリックスを直接いじって編集もできるし、すごいなこれ。
しばらく遊ぶことにしよう。 grails-1.0内蔵のデータベースはまだHSQLDBだった。 >>62
ｵﾊﾖｰ!!
∧∧ ∩
(`･ω･)/
⊂ ノ
(つノ
(ﾉ
＿＿_／(＿＿_
／ (＿＿＿／
￣￣￣￣￣￣
ん〜、だめだ。
こいつの使いやすさに慣れてしまうと、他のRDBMSが面倒に思えてきてしまう。
JRE と h2.jar あればどうにでもなっちまうし、
CSVRead/Write でデータ作成・取り出しが鬼のようにも楽だ。
なんかまとめっぽいサイト見つけたんで、貼っておく
ttp://homepage2.nifty.com/yoks/TechNote/H2/H2_MnFrm.htm あのさ・・・・JBossのDataSourceとしてH2を設定できたやつっている？
何か、EOFExceptionから逃げられない・・・・
hsqldb-ds.xml を書き換えたりして、やってみようとしてるんだけど・・・・ H2とJ2Seの各最新版でembeddedなアプリつくってて1.6GHzのXPのPCで
INTの5列の単純なテーブル(インデックスはprimaryと個別に2カラムのの計2個)に
PrepareStatementで新規データをMERGEをしようとしています
ListからループでsetしてaddBatchしてexecuteBatchしてcommitすると
executeBatchのところで、100件なら100ms、1000件なら1000msかかるんだけど
遅すぎませんか？こんなものなの？もちろんautoCommitはオフにしてます
でも、batchを止めて、1件ごとにexecuteUpdateしても、ほぼ同じ時間が掛かる
Batchの使い方間違えてるのかな…
1000データ×40タイプ×5000件のデータをデータベースに登録するのに一晩では終わらなかったです
Turion 64 X2 TL-60 2.0GHz Vistaで試してみたけど
1,000件で150ms
10,000件で650msだったよ、 >>67
早速のご回答ありがとうございます。
やっぱり私のは遅すぎるようですね…10倍近く違うとは
何かどこかで変な事をやってる臭いですね
再度ソースを洗ってみます
ところで、MERGEはEXPLAINできないんですね。怒られました アプリから該当のCREATE TABLEとMERGEだけ抜き出して
ダミーのmainに貼り付けてダミーデータで実行したら>>67と同等の結果が出ました
何が悪いんだろう…
考えられるのは、他の、DB全体の要因などでしょうか？
例えばテーブル数が多すぎて参照に時間が掛かっているとか…
問題のテーブル以外にも外部キー設定したテーブルが100近くあります
これからテーブル数を変更してテストしてみます 最近のバージョンアップでも地味に機能が追加されてるな
ついに行ロックのコードも入りはじめたみたいだし 行ロックに対応したら有り難いなあ
用途が広がりそう >>73
俺はExecute Queryってツールを使ってるよ。
http://executequery.org/index.jsp
そういえば、1.0.79で行レベルロック機能が有効になったと思ったら、
そのすぐ後に1.1.100も出てきて、ここしばらく動きが速いね。 eclipse 使ってるなら DBViewerプラグインが良いよ。
ttp://www.ne.jp/asahi/zigen/home/plugin/dbviewer/about_jp.html なんか "GROUP BY" がおかしくない?
CREATE TABLE TESTTBL(
A INTEGER NOT NULL
, B INTEGER NOT NULL
, PRIMARY KEY(A, B)
);
INSERT INTO TESTTBL (A, B) VALUES (1, 1);
INSERT INTO TESTTBL (A, B) VALUES (1, 2);
INSERT INTO TESTTBL (A, B) VALUES (2, 1);
INSERT INTO TESTTBL (A, B) VALUES (2, 2);
SELECT B FROM TESTTBL GROUP BY B;
DROP TABLE IF EXISTS TESTTBL;
これで期待する結果は
1
2
なのに
1
2
1
2
が返されるだけど… 普通に2件返るよ。
ver1.0.67でちょっと古いけど。 なるねぇ
> SELECT B FROM TESTTBL GROUP BY B;
> B
> 1
> 2
> 1
> 2
> (4 行, 0 ms)
@H2 1.1.100(2008-10-04)
Oracle10i で2件、Postgres8.3で2件、H2 1.1.100で4件なのを確認した。 うーん、公式に投げた方が良い気がする。どこで変わったんだろう。 うお、人が居る!
すんません、>>77です。
ゴメンナサイ、これは言葉が足らなかった…
>>77の様な場合に2件返すタイプのDBも、4件返すタイプのDBも存在します、たしか…
4件返すタイプはDB2とかだっけなぁ、忘れちゃった
個人的に4件返すタイプのDBが嫌いなので書いちゃっただけです…
古いバージョンは知らないのですが、
Version 1.0.73、 Version 1.1.100 共に同じ結果で
4件返されます
贅沢言わせて貰えれば、"SET MODE"でこの辺も反映してもらえると最高!
てっ、ゆーかもうバージョン上がってるし…
最新は Version 1.1.101 (2008-10-17) の模様
まだ未確認だけど そして誰も居なくなった…
個人的感想をチラ裏にメモ
まだオプティマイザがお馬鹿ちゃんなのかな？
簡単な場面ですぐにテーブルスキャンにいってしまう
っていうか、テーブルスキャンが他のDBより極端に遅いかもしれない
特にデータ量が多い場合に顕著な気がする
もしかしたらキャッシュが効いてる場合と、
そうでない場合のギャップがすさまじいのかも
良く言えば、
単テーブルを対象としたクエリの場合はとても素直なので、
インデックスの勉強にはいいかもしれない…
良く言えばだが…
特に、結合した場合はうまくインデックスを利用できてないっぽいし、
多量のデータを対象とした集計を行う場合にも、
どうしようもない位遅い…
悲しい程に…
期待age そうそう、素でオプティ米座に頼ると遅いね
キリキリ自分でチューンすると何とか動かせるレベルになるけど
経験無いと辛いかもしれん 知らない間にまたバージョンが上がっていたよ、パトラッシュ…
Version 1.1.104 (2008-11-28)なんだって…
最近バージョンアップが頻繁なんだよ…
ぼくは H2 を気に入っているんだ…
だから心配なんだよ…
stable のリリース時期が決まっていないのに
unstable を次々リリースしている事に…
僕には unstable を追っかけるのは無理だったんだ…
パトラッシュ…
僕なんだかとっても眠いんだ… ってゆか
書きたかった事を忘れてた…
Version 1.1.100 (2008-10-04)では問題の無かった"LINKED TABLE"関連(多分ストアドとか"ALIAS"も)
が
Version 1.1.103 (2008-11-07)で壊れているのかも…
正確に言うと jdbc ドライバ等、つまりはクラスパス関連が調子悪いかもね…
でも、期待age 以前のバージョンで普通に動いていたWindows サービス化が
ビタイチ動かねえとサービス実行ユーザやら権限やら散々確認して、
ふと確認したwrapper.confのjar名がh2.jarで最近のh2-1.1.x.jarみたいな
バージョン後置のファイル名に追随してないだけだと気付いた際の脱力感について。 JPのGoogleGroupのオーナーの知り合いって
いないんですかね？
Thomasが
＞I like to delete the spam messages
＞in this forum. The person / company that started this Japanese Forum
＞does not respond unfortunately.
http://groups.google.co.jp/group/h2-database-jp/browse_thread/thread/8a5714506a4b3145#
ってスパム消したいけど・・・って困ってるみたいなんですけど。 というか自前でフォーラム建てろよ…
もちろんバックエンドを H2 でさぁ…
組込み特化だけで終わる気なら別にいいんだけどさぁ…
つか、開発自体にパワーを割きたいのはわかるけどさぁ…
フィードバック自体が少な過ぎるのも問題だよ… >>90
オーナーと連絡取れたみたいですね
よかったです
でも、Thomas、マネージャになってもいいと思うんだけどメンバーだよねぇ・・・ >>91
>自前でフォーラム
>>23という経緯があるから難しいんじゃないかな >>63
∧,,∧
( `･ω･) ｳｰﾑ…ここは？
/ ∽ |
しー-Ｊ
try
{
net.2ch.pc11.test.read.db.H2DB.currentThread.getUser();
}
catch (NullPointerException e)
{
System.err.println("ぬるぽ");
System.err.println(e.toString());
} Version 1.1.110 (2009-04-03) released
ttp://www.h2database.com/html/changelog_ja.html Version 1.1.111 (2009-04-10)
ttp://www.h2database.com/html/changelog_ja.html
大きいトランザクションを実装したとき問題になることって何でしょうか？
>>99
本当に、こんな大きいトランザクションが必要なのか？
実装中にそんな事を考え続け、
眠れない夜を過ごすのは大いに問題
その後、過去の自分の実装を思いだし、
こうしとけば良かった、ああしとけば良かった、
と思い悩み、悶々し続けるのも問題 トランザクションが終わらないのが問題なのかどうか判明するまで時間がかかる
まぁ、デバッガで接続してるときはトランザクション開いたままだから
タイムアウト気にするけどね。
普通は、大きなトランザクションを作らないようにするのが問題少ないって。 H2を利用して初めてWebアプリを開発してます。
H2の利用は初めてじゃありません。
で、いろいろWebで調べるとH2のJarファイルを、例えばTomcatだと
common/libの下に入れるのがセオリーっぽいのだけど、アプリケーションコンテキストの
WEB-INF/libの下に入れて開発されている方いらっしゃいますか？
また、WEB-INF/libの下に入れることによるデメリットをご存知の方、教えてもらえないだろうか…。 >102
Tomcatのデータソースを使うならばcommon/lib下で。
使わないならWEB-INF/libでもいいかと。JDBC直呼びの場合など。
参考までに、オープンソースのグループウェア「GROUP SESSION」は
WEB-INF/lib下にh2.jarを配置する構成でした。 >>103
アドバイスありがとうございます。
とりあえず、WEB-INF/libの下に置いてのんびり開発してます。
なにか問題があったら報告します。
H2がもっと活気付くといいなぁ…。他力本願はよくないか^^; 個人的にはリンク機能に注目してる
あんま検証してないけどね…
ACCESSみたいなフロントエンド作ろうかなぁ Version 1.1.112 (2009-05-01)
ttp://www.h2database.com/html/changelog_ja.html >>95
∧ ∧ 一人一個まで
( ´・ω・)
（ ∪ ∪ ,.-、 ,.-、 ,.-、 ,.-、 ,.-、 ,.-、 ,.-、
と＿_）__） (,,■) (,,■) (,,■) (,,■) (,,■) (,,■) (,,■)
梅干 高菜 おかか こんぶ ごはんですよ わさび漬け 焼たらこ
,.-、 ,.-、 ,.-、 ,.-、 ,.-、 ,.-、 ,.-、
(,,■) (,,■) (,,■) (,,■) (,,■) (,,■) (,,■)
鶏飯 明太子 ちりめんじゃこ ゆかり 柴漬 塩辛 牛肉しぐれ
,.-、 ,.-、 ,.-、 ,.-、 ,.-、 ,.-、 ,.-、 ,.-、
(,,■) (,,■) (,,■) (,,■) (,,■) (,,■) (,,■) (,,■)
鮭 鶏ごぼう 野沢菜 天むす ツナマヨ エビマヨ 鮭マヨ 具なし
1.1.114から、JRE 1.5 必須になったね。
JRE 1.4 で動かすなら Retrotranslator 使えってことらしい。 いつの間にか 1.1.115 が来てた。
“The new storage mechanism”って、今までのものと何が違うんだろ？ Version 1.1.115 (2009-06-21)
ttp://www.h2database.com/html/changelog.html
>>109
なんか pageStore とか言うエンジンを作ってるっぽい
まだアルファっぽい
ページング出来るインメモリストレージエンジンみたいな感じ？
HSQLDB で言う CACHED に近いものかな？ >>110
色々調べてたら、↓こんなのが引っかかった。
「Re: Java 1.5, but still support Java 1.4 using Retrotranslator, Retroweaver, or using -target jsr14」
http://www.mail-archive.com/h2-database@googlegroups.com/msg01773.html
>> The performance on Flash (NAND) file systems is also fairly poor
>> mostly because of the large number of small write operations executed
>> by H2.
> This should be solved in the new storage mechanism ('page store').
SSDに最適化したストレージ機構を別途作るってことっぽいね。
ファイルへの書き込みを細切れに行わず、ある程度まとまった単位で行うことで、
SSD使用時のパフォーマンス劣化を防ぐ……んだと思う。 1.1.116来てるね。
Page Store については
> still experimental, and the file format will change, but it is quite stable now.
らしい。 Version 1.2.122 (2009-10-28)
* The native fulltext search now supports streaming CLOB data.
* If the database URL ends with ;PAGE_STORE=TRUE and a database in the old format exists,
it is automatically converted to the new page store format if possible. A backup of the database is created first.
Automatic conversion is not supported if the database was not closed normally (if it contains uncommitted transactions).
* Dropping the current user is now allowed if another admin user exists.
* Values of type BINARY or BLOB could not be converted to the data type OTHER.
* SHUTDOWN COMPACT now fully compacts the database.
* New system properties h2.maxCompactCount and h2.maxCompactTime to allow changing the default behavior (at most 2 seconds compacting when closing the database).
* New sorted insert optimization (see Performance / Database Performance Tuning).
* Issue 116: The files h2*-sources.jar and h2*-javadoc.jar are now in the Maven repository.
* Page store: opening a large database was slow if it was not closed before.
* Page store: new write and read counters in the meta data table.
Use SELECT * FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME IN( 'info.FILE_WRITE_TOTAL', 'info.FILE_WRITE', 'info.FILE_READ', 'info.CACHE_MAX_SIZE', 'info.CACHE_SIZE')
* The SQL syntax is documented using (railroad) diagrams. The diagrams are HTML.
* The documentation is no longer available in Japanese because the translation was too much out of sync.
Please use the Google translation instead.
* Certain queries were not sorted if subselect queries were involved
* More bugs in the server-less multi-connection mode have been fixed: 90097 The database is read only,
caches must be cleared on reconnect, etc. Version 1.2.123 (2009-11-08)
* Page store: new databases can not be opened with older versions.
* Page store: updating large rows (rows with more than 2000 bytes of data) could corrupt the database.
* Page store: inserting very large rows failed with ArrayIndexOutOfBoundsException.
* When using multi-threaded kernel mode,
setting disabling locking (LOCK_MODE=0) will now throw an exception.
At this time this combination will result in corruption when multiple threads try to update the same table.
* The fulltext search methods and fields are now protected instead of private, to make the classes more easily extensible.
* The Lucene fulltext search now also returns the score.
* New function SCOPE_IDENTITY() to avoid problems when inserting rows in a trigger.
* Statement.getGeneratedKeys() returned the wrong value if a trigger changed the identity value after inserting the row.
* Improved error messages: identifiers and values are now quoted.
* Improved error message when casting a value failed: the column name and type is included in the message.
* Improved support for GAE for Java thanks to Vince Bonfanti. Version 1.2.124 (2009-11-20)
* Clustering: there is now a way to detect which cluster instances are running.
* ConvertTraceFile: the SQL statement statistics are better formatted (newline are removed).
* The file lock thread is now stopped when the database is closed.
* Issue 140: the Script tool now supports writing to a stream.
* Issue 138: the trace output of Statement.execute(String, int) and executeUpdate was incorrect.
* Page store: new databases can not be opened with older versions.
* Page store: multi-column indexes didn't work if the cache was very small.
* Page store: opening a database could theoretically result in an endless loop.
* Page store: adding large indexed columns could get very slow.
* Page store: after a duplicate key exception,
an ArrayIndexOutOfBoundsException could be thrown (only for very large rows).
* Page store: the recover tool sometimes generated a script file that contained duplicate data.
* Page store: sometimes opening a read-only database failed.
* Page store: opening a database sometimes failed if large rows where updated,
or if a table was truncated before.
* Page store: when using a very small page size (128 bytes or smaller),
writing a large row could result in an endless recursion. This is only a theoretical problem, as the page size is 2 KB.
* Page store: getting the min value from a descending index with NULL entries could return the wrong result.
* Page store: improved auto-recovery after power failure.
* The JDBC client did not detect that it was not talking to an H2 server.
This could result in strange exceptions when trying to connect to another kind of server.
* User defined functions can be created with source code.
Example: CREATE ALIAS HI AS 'String hi() { return "Hello"; }'
* Database file lock: the exception "lock file modified in the future" is longer thrown; instead,
opening the file will be delayed by 2 seconds.
* Inserting LOBs got slower each time the process was restarted.
It could loop endlessly after about 1000 process restarts.
* Issue 117: Multi-version concurrency: concurrent MERGE statements now work.
* Improved read-only database detection. Version 1.2.125 (2009-12-06)
* Lucene fulltext search:
the Lucene field names now match the table column names,
except if the column names start with _ (in which case another _ is prepended).
Unfortunately this change means existing fulltext indexes need to be re-built.
* The shell tool now has a very simple statement history.
* The zip file system implementation now supports the '~' home directory prefix.
Example database URL: jdbc:h2:zip:~/test.zip!/test
* Right outer joins on tables that were already 'inner joined' was processed incorrectly.
* Temporary files from LOB objects were not deleted early enough when using the server mode.
* Trying to alter a temporary table threw a strange exception.
It is still not possible to do that, but the exception message is better now.
* When the system property h2.maxMemoryRowsDistinct was set,
and using SELECT DISTINCT, the temporary table was not correctly dropped.
This could cause problems in recovery when the process was killed.
* Trigger that are called before a select statement are now supported.
This allows to create tables that work like materialized views.
* Non-row based triggers were called even if the action didn't match the declared action
(INSERT triggers were also called when deleting rows).
This has been changed. The MERGE statement calls both INSERT and DELETE triggers.
* Statements with IN(..) conditions could produce the wrong result or a data conversion error (since version 1.2.120).
Examples: index on id, name, condition: id=1 and name in('Hello', 'x');
index on id, query: select * from (select * from test) where id=1 and name in('Hello', 'World').
* The CompressTool was not multithreading safe.
Because of this, the following database operations where also not multithreading safe (even when using different databases):
the SCRIPT command (only when using compression), the COMPRESS function,
and storing CLOB or BLOB data (only when compression is enabled).
* The compression algorithm "LZF" is now about 33% faster than before when compressing small block (around 2 KB).
It is much faster than Deflate, but the compression ratio is lower.
Some of the optimizations are from Sam Van Oort, thanks a lot!
* Compressing large blocks of data didn't work when using the "Deflate" compression algorithm.
Compressing a lot of data could run out of heap memory.
* The test cases don't access the file system directly,
this simplifies GAE for Java testing. Thanks to Vince Bonfanti.
* More bugs in the server-less multi-connection mode have been fixed.
* When running against an old database,
the SCRIPT statement could generate a SQL script that contained duplicate indexes (PRIMARY_KEY_E).
* JdbcConnectionPool.getConnection() could throw a NullPointerException.
* User defined functions: the source code is now available using SELECT SOURCE FROM INFORMATION_SCHEMA.FUNCTION_ALIASES.
* User defined functions with source code didn't work after re-opening the database.
* The newsfeeds are now Atom 1.0 standard compliant.
* The database is now closed after an out of memory exception, because the database could get corrupt otherwise.
* Better error message if both AUTO_SERVER and SERIALIZED parameters are set to TRUE.
* Drop table did not delete lob files in old file store (not PAGE_STORE). ちょっとスレ違いな話かもしれませんけど、
RDBの最適化について質問させてください。
主キーがint型のテーブルで、10億個のデータが入っているとします。
このときに、次のどちらが効率的だと思いますか？
・一つのデータベースに10億個のデータを入れておいて、
主キーで検索した場合。
・2つデータベースに5億づつデータを入れておいて、
検索するキーが5億未満の場合はデータベースAを、
検索するキーが5億以上の場合はデータベースBを
検索するように分岐する場合。
単純に量が多い場合は後者が効率的だと思うのですが、
それは正しいでしょうか？ 検索は前者、更新は後者が効率的。
パーティショニング機能のあるRDBMSを探して
その質問スレへどうぞ。 テーブルの使用済みバイト数とか、使用率なんかを見る方法を知りませんか？
INFOMATION_SCHEMAを見てもそれらしいのが見当たらなくて。 Version 1.2.131 (2010-03-05)
http://www.h2database.com/html/changelog.html
・Older versions of H2 (version 1.2.127 and older) could not connect to a new version
(version 1.2.129 and newer). The connection blocked when trying to connect. Now the
connection no longer blocks, instead a SQL exception is thrown.
・In versions 1.2.129 and 1.2.130, a database could not be opened sometimes after
dropping tables or indexes, and then creating new indexes for existing tables. The
exception contained the text "parent not found" (version 1.2.129) or "Table not found"
(version 1.2.130).
今回のバージョンアップは、下位バージョンとの互換性という点では要注意っぽいね。 画像ファイルをJavaでString（byte[]）に変換して
VARCHAR(max)にいれてみたいんだけど
H2DBのVARCHARってどのくらい入れられる？
MByteのデータ入れられるといいんだけど。。。 なぜVARCHAR？
BINARYかBLOBにしとけよ >>131
http://www.h2database.com/html/datatypes.html#varchar_type
> The maximum precision is Integer.MAX_VALUE.
※Integer.MAX_VALUEは 2^31-1 ね。
個人的には、なぜバイナリーデータである画像データを、
本来文字列を入れるために用意されたVARCHAR型に入れようとしてるのか、
その理由が知りたいな。
本来なら、バイナリーデータを格納するという用途には
BLOB型かBINARY型を選択するところだと思うけど…… >>134
varcharは圧縮されて容量が多少すくなくなるらしいんだ
それでメディアファイル（画像とかmp3）をいれるとして
小さなメディア、大きなメディアファイルが混在する
数メガのカラムがあるとしたら圧縮された方がいいかなっと
でも本当の理由はバイトデータをbase64の文字列にして
保存するってwebのどっかで見かけて見かけたのが発端 画像データをそれ以上圧縮するのは難しい
逆にBASE64の分だけ膨らんでしまうよ >>135
DBにデータを格納する時点でバイナリーをシリアライズ（今回はBase64）する
必要性ってドコにあるんだろうかと、ちょっと考えてみた。
例えばに画像うｐろだみたいに、DBへのデータ挿入に比べて、DBからのデータ取得が
圧倒的に多いような場合で、「DBからバイナリーでデータ取得した後のBase64変換処理が惜しい」
というような非機能要求があるなら、VARCHARにシリアライズ済みデータを持つというアイディアも
“アリ”なのかな、とは思う。実際にどの程度効果があるかについて検証する必要はあるけど。
ともかく、なぜ“シリアライズ後のデータ”を「DBに」持たせるのかについて、
もう少し詳細に考えてみた方がいいような気はする。個人的にはどうも、セオリーから外れた
DB設計をしている印象がぬぐえないっスよ。 質問者だけどBLOBかURLで
画像データを扱うことにするよ
ありがとな Version 1.2.132 (2010-03-21)
http://www.h2database.com/html/changelog.html
・The implementation of a Java to C (source code level) converter has been
started. The plan is: it should be possible to convert H2 (or a part of it) to C so
that the database can be run without a JVM. This will be a long term project (it
may take a year or so).
がんがれー！ ディスクIOがボトルネックになっている場合は、
256上限のカラムをバイナリ指定で１バイトとかにした方が良いのかな？
インデックス効きづらくなったりする？ >>139
Cで動かすと重くなったりしそうなんだけど
DBって結構低レベルなロジックが多いからパフォーマンス出たりするかな？
GCがあって、ネイティブが書き出せるGoへのコンバートとか
出来たら面白いような気もする。 javaから起動終了したいんだけど
シャットダウンでExceptionになるんだ。
間違ってる？
String port = "9999";
Server server = Server.createTcpServer("-tcpPort", port);
server.start();
Server.shutdownTcpServer("tcp://localhost:" + port, password, false); >>148
server.stop()じゃいかんの？
リモートからシャットダウンしたいの？ passwordはあってる？
なんにしてもExceptionの内容をまず貼らないとｗ >>150
start()と対になるのはstop()なの？
stopとshutdownの違いが分からないや
javadocに何も書いてないしわけわかめ >>152
ttp://www.h2database.com/html/tutorial.html#using_server
チュートリアルのここら辺？ H2はシェルスクリプトからsql実行という方法はできますか？ 
