off"にしたらちゃんと返ってきた」で、解決したと思ってたんですが。BY」が指定されていない場合は、SQLの結果の順番は保証されません。TABLEみたいなものと思ってたけど、ちょっと違うみたい。HiRDBのマニュアルの記述読んでも???なんで。データベースPostgreSQLではVACUUMコマンドでってのがあるの知ってたけど、HiRDBも同じようなのがあるらしい。Readを前提としたロジックがあるのはいいとして。なんか、その辺りと排他とインデックスの話が関係しているような気がしないでもない。同じスレッドで、2つのConnectionオブジェクトによりデッドロックを起こそうとすると、タイムアウトのエラーになる。HiRDBHiRDBではTruncateTableではなくPurgeTabelになります。データベースここでの検証がキッカケになって、排他制御のロックがかかりっぱなしになってる原因の、実際動いてるアプリケーションのコードの問題箇所が判ったよ。NULLだけど、ユニークキーはNULLもOKくらい?かと思ったけど、なんか違うらしい。そりゃなんか違うんじゃろうけど...何がどう違うんかよー判らん。し、だからってpdloadコマンドの挙動が違うってのも...みたいな。HiRDBインポートするpdloadコマンドの制御情報ファイルの記述に、”fes1:”という記述がないとこんなエラーがでます。HiRDBここでプーリングは断念した訳ですが。HiRDBプーリングの問題とは違うようなんだけど、KFPA11723-EってなメッセージのExceptionが。コネクションのクローズと勘違いしてたけど、データソースでクローズしてみるとか。commons-poolのレベルでは、こんなのとか。HiRDB単純にorg.apache.commons.dbcp.BasicDataSource#getConnectionメソッドを、そのまま使ってたのが判明したり。こいつでコネクション取得せずに、commons-dbcpのレベルでの実装を使ってただけだった。SQLHiRDBってSELECT文の結果の順番が、実行する度に変わるんね。HiRDBデータをインポートするコマンドですが。メッセージが出てきました。