私はJava JDBCの自動コミットモードについてはあまりよく分かりませんが、自動コミットモードがfalseに設定されています。その後、私はうまく動作するデータベース上の選択クエリを発生させる、私はコミットが挿入、更新、削除ステートメントに対してのみ呼び出されなければならないという印象を受けています。自動コミット偽モードjava
Selectクエリの接続をコミットする必要がありますか？そうでない場合、そのテーブルは他のトランザクションのためにロックされますか？
ありがとう、 Rohit。
あなたの孤立度によって異なります。 READ COMMITTEDを使用する場合、SELECTはSELECT FOR UPDATEを指定した場合にのみロックを作成します。 REPEATABLE READ以上を使用すると、すべてのSELECTはロックを作成する可能性があります（データベースモデルによって異なります）。
私はJava JDBCの自動コミットモードについてはよく分かりませんが、自動コミットモードがfalseに設定されています。その後、私はうまく動作するデータベース上の選択クエリを発生させる、私はコミットが挿入、更新、削除ステートメントに対してのみ呼び出されなければならないという印象を受けています。
これはアプリケーションによって異なります。単純な更新、挿入、削除がある場合は、の自動コミット=をに残すことができます。一般的に、それは自動コミットをオフにすることをお勧めします。この構成により、アプリケーションの柔軟性とパワーが向上します。複雑なトランザクションを使用することができ、トランザクションの開始時期と終了時期を決定できます。
ここでSelectクエリの接続をコミットする必要がありますか？そうでない場合、そのテーブルは他のトランザクションのためにロックされますか？
いいえ、select statmentはトランザクションを開始しません（挿入、更新、削除）ので、select文の後にコミット/ロールバックする必要はありません。選択された行をロックしてトランザクションを必要とするselectの特別なケースが1つあります - with for update clause
これは間違っています。すべてのJDBCステートメントは、SELECTを含むトランザクションコンテキストで**常に**実行されます。 – ChssPly76
本当ですか？ selectクエリでトランザクションが開始されると、ortherセレクトのデータがブロックされます。 Selectは既存のトランザクションで実行できますが、新しいトランザクションは開始しません。 – cetnar
@cetnar - 私は肯定的です。データベースに対して実行された文（SELECTを含む）は、トランザクション・コンテキスト内で実行されます。以前のトランザクション（もしあれば）がコミット/ロールバックされた後に、既存のトランザクションまたは新しい（別個の）トランザクション内で実行することができます（DDLを除く場合もあります）。詳細については、JDBCチュートリアル（http://java.sun.com/docs/books/tutorial/jdbc/basics/transactions.html）または仕様を参照してください。 – ChssPly76
http://java.sun.com/j2se/1.3/docs/api/java/sql/Connection.html#TRANSACTION_REPEATABLE_READ - 何もありませんロックを作成するselect文についてロックはDML文によって作成されます – cetnar
Oracleデータベースで「SELECT FOR UPDATE」を実行すると、同じレコードで「SELECT FOR UPDATE」を実行すると、2番目のトランザクションがブロックされます（ロックを待機します）。 – tangens
@tangens私は定期的にセレクトを意味します。私はどのような場合でも更新の作成ロックを選択するという私の回答を指摘しました。 'REPEATABLE READ'分離モデルでは、regular selectはロックを作成しません。分離モードは、この変更によって影響を受ける選択されたデータに対して、コミットされていない変更およびルールに準拠しています。 – cetnar