アカウント名:
パスワード:
キャッシュと本物が互いの排他をとって互いに更新しようとしたんじゃない?
システム構成図見る限り、アプリケーションサーバにキャッシュを持たせるという構成がそもそもダメだと思う。素直にデータベースサーバを増強するか、百歩譲っても、そういうトリッキーな構成を採るなら、きちんとデータの整合性が確保できるようにデータ更新のお作法の基準を決めてレビュー項目・テスト項目に入れておかなくちゃダメだろ。だいたい、ロック機構を入れてデッドロックが起こったということは、実はこれまでもデータの上書きが発生してたけど、問題が露見しなかっただけという可能性も十分考えられる。システム組む人なら、まずは、あの構成図見て「これはイカン」と感じるセンスが必要だと思う。そして予算がなくて工夫でカバーするにも、それなりの手当てが必要だということも理解しないと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
キャッシュの排他制御機構? (スコア:2)
Re: (スコア:0)
キャッシュと本物が互いの排他をとって互いに更新しようとしたんじゃない?
Re: (スコア:3, 参考になる)
・キャッシュは、ほぼ読み込みのみ
・ディスクは、読み書きがある
・キャッシュとディスクはネットワーク上の別ノード
当初
・ディスクのみ排他処理アリ
パッチ後
・キャッシュ、ディスクともに「個々に」排他処理アリ
問題点
・トランザクション的に次の2パターンがあった
1.キャッシュアクセス → ディスクアクセス
2.ディスクアクセス → キャッシュアクセス
・キャッシュアクセス、ディスクアクセスで別々に排他処理をしていた
開けてみればシンプルなデッドロックではありますが・・・・
Re:キャッシュの排他制御機構? (スコア:4, 参考になる)
システム構成図見る限り、アプリケーションサーバにキャッシュを持たせるという構成がそもそもダメだと思う。
素直にデータベースサーバを増強するか、百歩譲っても、そういうトリッキーな構成を採るなら、きちんとデータの整合性が確保できるようにデータ更新のお作法の基準を決めてレビュー項目・テスト項目に入れておかなくちゃダメだろ。
だいたい、ロック機構を入れてデッドロックが起こったということは、実はこれまでもデータの上書きが発生してたけど、問題が露見しなかっただけという可能性も十分考えられる。
システム組む人なら、まずは、あの構成図見て「これはイカン」と感じるセンスが必要だと思う。そして予算がなくて工夫でカバーするにも、それなりの手当てが必要だということも理解しないと。