21 
    java.sql.SQLException: Lock wait timeout exceeded; try restarting tra
nsaction at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.ja
va:2077)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:
2228)
        at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:
208)
        at org.hibernate.loader.Loader.getResultSet(Loader.java:1812)
        at org.hibernate.loader.Loader.doQuery(Loader.java:697)
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Lo
ader.java:259)
        at org.hibernate.loader.Loader.loadEntity(Loader.java:1885)
        ... 131 more

レコードを更新しているときに、ロックタイムアウトが例外を超えて繰り返し発生します。

Java Struts2.1Hibernate構成を使用しています。使用されるDBはMYSQLです。

誰もがそれを解決する方法を知っています..??

4

7 に答える 7

21

ここにいくつかの提案があります：

  1. 「<strong>ロック待機タイムアウト」は通常、トランザクションが他のトランザクションによってすでにロックされているデータの行の更新を待機しているときに発生します。
  2. ほとんどの場合、問題はデータベース側にあります。考えられる原因は、不適切なテーブルデザイン、大量のデータ、制約などである可能性があります。
  3. この手の込んだ答えをチェックしてください。
于 2012-12-20T07:40:32.050 に答える
6

これは、このStackOverflowの記事のように、次のアノテーションの誤用によっても発生する可能性があります。

@Transactional(propagation = Propagation.REQUIRES_NEW)
于 2016-11-14T10:12:18.373 に答える
5

データベーステーブルがInnoDBストレージエンジンとREAD-COMMITTEDトランザクション分離レベルを使用していることを確認してください。

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;mysqlコンソールで確認できます。

READ-COMMITTEDに設定されていない場合は、設定する必要があります。設定する前に、mysqlでSUPER権限を持っていることを確認してください。

http://dev.mysql.com/doc/refman/5.0/en/set-transaction.htmlからヘルプを利用できます。

これを設定することで、あなたの問題は解決すると思います。

ありがとうございました。

于 2015-01-23T12:31:37.190 に答える
1

（DB固有の回答を尊重して無視します）

すべてのDBトラフィックがシングルトンクラスを介してチャネリングされる正式なCRUDスキーマを使用する場合でも、スレッドロックが発生する可能性があります。これは多くの場合、あなた自身、大学、およびHibernateチームの間の見落としが原因で発生します。したがって、バグがないか独自のコードを確認するのが最も迅速です。特に、hibernateのコアルールに注意を払ってください。

通常、CRUDインターフェイスには、共通のプライベートメソッドを共有するパブリック'Create'、'Read'、'Update'、および'Delete'メソッドがあります。これは、DRYのベストプラクティスのために行われます。ただし、そうすることで、これらのメソッドはほとんどの場合問題なく機能しますが、常に機能するわけではありません。

では、スレッドロックをテストして解決する方法は？

確認：

  • session.save(myObj)アクションは最初にPKの一意性をチェックします

  • すべてのuniqueResult()クエリは確かに1つの結果を返します。

    （重要！）フォーカステストケース：

    • PK重複を導入する
    • 存在しないレコード/エントリ/行を更新/読み取り/削除します

最後に、@AfterSuite（TestNG）を使用してすべてのテーブルエントリを削除します。実装が不十分だと、前述の操作で別のスレッドロックが発生します...そうでなければ、あなたは金色になります。

于 2015-05-22T10:44:38.977 に答える
1

取り外し@Transactional(propagation = Propagation.REQUIRES_NEW)て確認してください。

于 2020-11-24T18:52:33.703 に答える
0

where句が最適化されているかどうかを確認します。つまり、主キーやインデックスを使用します。

于 2015-07-29T18:21:07.000 に答える
0

上記のすべてが機能しない場合は、mysqlログからのエラーメッセージを確認してください。ログファイルのサイズについて言及されている場合は、構成でログファイルを増やして、mysqlサーバーを再起動する必要があります。

于 2017-01-03T17:13:50.977 に答える