最終的にブロックがリソースを閉じるのに本当に信頼できるかどうか疑問に思いました。データベース接続など?
私たちのアーキテクトによると、特にWebアプリケーションのシナリオでは、最終的にブロックはデータベース接続を閉じるのに信頼性がありません。
理論によれば、最終的にブロックは、コードの実行ステータスに関係なく、ロジックフローの最後で実行する必要があります。最後に、ブロックがベストプラクティスです。
JDK-1.4、プレーンSQLクエリを使用し、接続プールからデータベース接続を取得するWebアプリケーションプロジェクトに取り組んでいます。ほとんどのSQLステートメントはネストされたステートメントであり、単一のメソッドには複数のStatementオブジェクトとResultSetオブジェクトが含まれています。
このシナリオでは、finallyブロックについて懐疑的です。テストによると、finallyブロックはリソースを解放せず、代わりにWebアプリがより多くの接続を取得しているためです。最後に、Tomcat5.5は2/3時間ごとにハングします。
次に、finallyブロックを削除し、SQL操作を実行した直後とcatchブロックでリソースを解放しました。その後、Webアプリはリソースを完全にリリースし、Tomcatはもうハングしていません。
したがって、私は最終的にブロックする理論について本当に混乱しています。
これがコードスニペットです。コーディング手法が間違っているかどうかアドバイスしてください。
... .. . . .. . .. . . .. .. .
........ . .. . . ... . .. . .
Connection dbCon = null;
Statement stmt1 = null;
ResultSet rs1 = null;
try {
dbCon = DB.getConnection();
stmt1 = dbCon.createStatement();
rs1 = stmt1.executeQuery("sql Query as String");
while(rs1.next()){
String col1 = rs1.getString("DB_COL_1");
int col2 = rs1.getInt("DB_COL_2");
String col3 = rs1.getString("DB_COL_3");
if(col3 != null){
Statement stmt2 = null;
ResultSet rs2 = null;
try{
stmt2 = dbCon.createStatement();
rs2 = stmt2.executeQuery("sql Query as String");
------- - ----
while(rs2.next()){
String col4 = rsTierMember.getString("DB_COL_4");
... . .. . . . .....
. .. . .. . . . . . ..
}
... . .. .. ... .
}catch(SQLException sqlExp){
} catch (Exception e) {
}finally{
try{
if(rs2!=null)
rs2.close();
if(stmt2!=null)
stmt2.close();
}catch(Exception ex){}
}
}
}
.... . .. .
}catch (SQLException e) {
} catch (Exception e) {
}finally{
try{
if(rs1!=null)
rs1.close();
if(stmt1!=null)
stmt1.close();
if(dbCon!=null)
dbCon.close;
}catch(Exception ex){
}
}
...... . . . . . ...
... . .. . .. . . .. .