1

私はstruts 2のトップリンクと使用率の高いアプリのトップリンクを使用しています。アプリは常に1秒あたり複数の読み取りと書き込みで単一のテーブルにアクセスします。これにより、lock_wait_timeout エラーが発生し、トランザクションがロールバックされ、入力されたばかりのデータがフロントエンドから消えます。(Mysql の自動コミットは 1 に設定されています)。例外はキャッチされ、アプリのエラー ページに送信されますが、ロールバックは引き続き発生します (mysql ではロールバック機能がオンになっていないため、これはトップリンクの例外である必要があります)。生データ ファイル ibdata01 は、エディターで開いたときにその中のエントリを示します。これがまれに発生したため、テスト条件で再現できませんでした。

このジレンマから抜け出す方法を提供してくれる親切な人はいますか? このような高アクセス (常に同じテーブルからの一定の読み取りと書き込み) には、どのようなアプローチが必要ですか? どんな助けでも大歓迎です。

4

2 に答える 2

1

同時読み取り/更新の性質は何ですか?異なるセッションから同じ行を絶えず更新していますか?2つのセッションが同じ行を同時に更新するとどうなると思いますか?

読み取りが更新と競合しているだけの場合は、データベースでのトランザクション分離を減らすことを検討してください。

複数の書き込みの競合がある場合は、ペシミスティックロックを使用して各トランザクションが確実に成功するようにすることを検討してください。ただし、どちらの場合も、多くの競合が発生するため、データモデルまたはアプリケーションでのデータの使用を再検討する可能性があります。

http://en.wikibooks.org/wiki/Java_Persistence/Lockingを参照して ください

于 2011-05-09T13:30:41.423 に答える
0

lock_wait_timeouts は、トランザクション データベースの現実です。通常の応答は、エラーをトラップしてトランザクションの再実行を試みることです。多くの開発者がこれを理解しているようには見えないので、繰り返します: lock_wait_timeout エラーが発生し、それでもトランザクションをコミットしたい場合は、もう一度実行してください。

他に注意すべき点は次のとおりです。

  • 永続的な接続を使用し、トランザクションを明示的に COMMIT しないと、実行時間の長いトランザクションが発生し、不要なロックが発生します。
  • 自動コミットがオフになっているため、mysql CLI (またはその他の対話型クエリ ツール) からログインしてクエリの実行を開始すると、行がロックされ、タイムリーに解放されない可能性が高くなります。
于 2009-11-09T14:35:15.383 に答える