Derby データベースが組み込まれたデスクトップ アプリケーションでは、アプリケーションの存続期間全体にわたって (データベースと対話するたびに再作成するのではなく) 何を維持する必要がありますか?
ConnectionそしてStatement、プログラムの存続期間を通じて同じステートメントを使用しますか?Connection、ステートメントを繰り返し再作成していますか?データベースのアマチュアの観点からは、再作成する必要のないものを再作成することを避けるのは合理的に思えますが、オプション 1 (または 2) は標準的な慣行に反するものですか、それとも明らかな短所がありますか? 接続とステートメントの (再) 作成は高価ですか?
組み込みのDerby アプリケーションでは、Connection オブジェクトと Statement オブジェクトの両方が非常に安価であり、必要に応じてそれらを作成することについて心配する必要はないと思います。Derby 単体テスト スイートでは、何万もの接続と何十万ものステートメントを問題なく作成できます。
Connection オブジェクトと Statement オブジェクトを必要なだけ保持しておくことも問題ありません。Embedded Derby には時間制限がなく、接続オブジェクトまたはステートメント オブジェクトを (クローズして) 指示しない限り、またはリークしない限りドロップしません。漏えいした場合は、ガベージ コレクターが (最終的に) それらをクリーンアップします。
接続を維持しても問題ありませんが、完了したらトランザクションを commit() する必要があります (もちろん自動コミット モードで実行している場合を除きます)。
また、結果セットを保持している場合は、通常、トランザクションをコミットすると結果セットも閉じられることに注意してください。ただし、コミット後に開いたままになる特別な結果セットを具体的に構築する必要はありません。
接続には確かにコストがかかります (数百ミリ秒かかる場合があります)。ただし、接続の有効期間は限られており、ステートメントと結果セットはその有効期間によって異なります。平均的な DB は、接続が 30 分以上解放されるたびにタイムアウトし、接続をドロップします。「自動的に」接続を再取得するように、コードにタイムアウト チェッカーを追加することもできますが、それは面倒な作業であり、内部でどのように動作するかを知らなければバグが発生しやすくなります。むしろ、 C3P0のような既存の完全に開発された堅牢な接続プールを使用し、JDBC コードを通常の方法で記述します (可能な限り短い範囲ですべてのリソースを取得して閉じます)。それだけです。
理論的には (そして明らかに実際にも) 組み込みデータベースでの接続は安価であり、接続は永久に存続しますが、JDBC コードで組み込みデータベースに別の方法でアプローチすることには強く反対します。JDBC コードに意味的な欠陥が生じ、完全に移植できなくなります。それを配布したり、より強力な実際のRDBMSサーバーに変更したりするときはいつでも、すべてを書き直して再実装する必要があります。