finally ブロックで close() を呼び出すと、接続が確実に閉じられるようになるため、どのリソースに対しても正しいことです。
私はそれを次のように書きます
val connection = DriverManager.getConnection(connection_string).unwrap(classOf[OlapConnection])
try {
[...]
} finally {
connection.close
}
varを取り除きます。しかし、これはまだ「命令型スタイル」なので、使用します
def withResource[T <: { def close() }, R](resource: T)(code: (T) => R): R = {
try {
code(resource)
} finally {
import scala.language.reflectiveCalls
resource.close()
}
}
一緒に
withResource(DriverManager.getConnection(...)) {
conn =>
[...]
}
コードを乱雑にする try/catch を取り除きます。さらに、閉め忘れもありません。これは、close() メソッドを提供するすべてのクラスに適用されます。withResource() メソッドをトレイトに入れると、それをクラスに混在させることができます。
接続プールに関しては、ここに別のスレッドがあります。
長時間実行される OLAP クエリについては、長時間実行されることは想定されていません。Essbase または Palo での経験は、これらのクエリがほぼ「リアルタイム」であることを示しています。ドリルダウンすると、唯一の問題は、クライアントに転送される大量のデータである可能性があります。結果を読んでいる間、受信データを進行状況表示を実装する手段として使用できます。OLAP データベースは非常に高速です。とにかく、クエリをバックグラウンド スレッドに配置して、コードがブロックされないようにすることはできますが、OLAP でこれを行う必要はありません。データをできるだけ早くフロントエンドにパイプするだけです。これがクライアント (Excel プラグイン) の動作です。