リビジョン管理できていれば、後勝ちでいいんじゃね？と思いつつ、も何も考えずに楽観的ロックでWebアプリを実装することが多いい件について。私は衝突があまり起こらないから楽観的ロックでいいという考えではなく、上書きが怖いからとりあえず楽観的ロックって感じで作っていた。なので、ロックの実装を判別する基準がおかしい。ただ「よく衝突するから悲観的ロックを実装しよう！」という結論に至ったこともない。あとは…楽観的って響きがなんだか惑わされる原因な気がする。「先がちの排他制御」とかのほうが良い気がする。
↑すごいなこのサイト拡張子は.aspxで、homeに行くとIISのエラーが返ってくる。話をはじめにもどすと、さほど重要でないデータは、すべてアップサートでいいのではないか。
どうしても整合性をとるためにロックが必要な場面では…とりあえず先に更新した人がいたら借り上書き（gitでいうところのstashをした後に）過去に上書きされている通知を出し、はじめのデータへロールバックをするのか？別の誰かが更新した内容にするのか？それとも、自分が上書きしようとしたデータに更新するのか？を選べると最高だと思うのだが。
以下は覚書。PHPの場合はこんな排他制御もできるらしい↓
複数のPHPをまたがってトランザクションや排他制御を行うことは出来ないのでしょうか？
mysql_pconnectというリクエストの後にもDB接続を維持するコマンドがあることを知った。ただしPHP7系では削除されており、mysqliやPDOにも昨日としては引き継がれているが使ったことがない。でもこれってブラウザを閉じたらどうなるんだろうか？サーバ側のセッションがタイムアウトされるまでテーブルをロックするのだろうか。質問者は独自にロックを実現したほうがいい気がしますが。
コメント