DBFluteのResultSetタイプのデフォルトは「SCROLL_SENSITIVE」です。 しかし、DB2のJDBCでは、「FORWARD_ONLY」にしないと 「BLOB/CLOB」のデータがフェッチできません。 よって、DBFluteConfigを使って、DBFluteのResultSetタイプの デフォルトを「FORWARD_ONLY」に変えてあげる必要があります。 で、実際にDBFluteDB2Exampleで自分でやってみたのですが、 「ページングのResultSet飛ばし」を指定するとJDBCにて例外が 発生してしまいました。 ResultSetのgetMetaData()で「result setがクローズされて...」 というような感じで。 そこの因果関係はまだ細かいところまで調査できていないのですが、 とりあえず言えることは 「BLOB/CLOB」と「ページングのResultSet飛ばし」が 両立していないというところです。 と、微妙に使いづらい状態にあるので、５月連休にでも調整します。 (DB2 + DBFluteのユーザの方はどれだけいらっしゃるのかな！？) row_number()関数を使って、「ResultSet飛ばし」を利用しない ってのをちょっと考えています。(内部的な話です) 【追記１】 もっと細かいところが判明しました。 現象は、「FORWARD_ONLY」かつ「ResultSet飛ばし」かつ「結果０件」 の場合に発生しました。「結果０件」がポイントです。 「FORWARD_ONLY」かつ「ResultSet飛ばし」の場合は、 ResultSet#next()で読み飛ばします。「結果０件」のときは 実質、最後のレコードのnext()を実行することになります。 すると、DB2のJDBCドライバがResultSetを内部でクローズしている ようで(恐らく)、その後にResultSetのgetMetaData()するので 「result setがクローズされて...」と怒られてしまうようです。 同じことをOracleでも無理矢理実現してみても発生しないので DB2のJDBCドライバ特有の動きのようです。 でもまあ、JDBCドライバからしてみれば、next()=falseで既に 終わっていることが判明しているので、それ以降になんかするのは やめてってのも分かる気がする。 BeanListMetaDataResultSetHandler#handle()の初っぱなで、 ループが回ることを確認せずに問答無用で「rs.getMetaData()」 ってやってしまっているのが良くないんだなぁ。。。 とりあえずDBFluteでいそいで応急処置します。 (無論、DB2のrow_number()化はそれはそれでやるべき課題です) 【追記２】 BeanListMetaDataResultSetHandler#handle()をどうにかしても だめでした。ResultSetが既に「クローズ」扱いなので、 rs.getMetaData()を回避しても「rs.next()」で同じ例外発生です。 うむぅ。。。 【追記３】 ひとまず、DB2のときだけ(かつ、FORWARD_ONLY)、 OffsetのResultSet飛ばしで「rs.next=false」になった場合は、 Wrapperの中のrs.next()にて固定のfalseを戻すようにしました。 (本物のResultSetに対してnext()を呼び出さない) 確かに、FORWARD_ONLYでrs.next()=falseになったら、 それ以降も論理的に必ず「s.next()=false」なはずなので、 おかしい処理ではない気もします。 但し、無論ピンポイント対応としての修正とします。 where DB2 and FORWARD_ONLY and offsetのResultSet飛ばしで「rs.next=false」 他のDBでも同じ現象が発生したら、「if (DB2だったら)」 のif文を調整することでするに対応が可能になります。
