Coarse Grained Lock は操作に含まれる個々のデータの単位ではなく、データ群をまとめてひとつの意味を成す単位で排他ロックを確保するパターンです。
Optimistic Offline Lock (楽観的ロック) には、更新操作の衝突を避けるための仕組みが必要です。ひとつの操作単位が複数のメカニズムにまたがると、一部が正常で一部が矛盾するような、判断の難しい状況を生みます。Git のブランチマージは変更行の衝突をとてもうまく検出してくれますが、同じ行を変更していなかったとしても、同じファイルを変更していると、マージ後にプログラムコードのロジックが矛盾する場合がありますね。複数のブランチ作業で、同じファイルやディレクトリに変更が発生しているときは要注意です。念のため rebase し、直列的なコード編集と考えるのが無難です。同様に、データのサブ構造の異なる部分を変更した操作だから排他的に扱わなくていいと思っていると、それぞれは正しい意図で行った操作が、全体としては矛盾する結果を生むことがあります。
Pessimistic Offline Lock (悲観的ロック) においても、ひとつの操作の中にいくつものロックポイントがあると、他の操作とのデッドロックを起こしやすくなります。デッドロックとは、A のロックを獲得してから B のロック解除を待つ処理と、B のロックを獲得してから A のロック解除を待つ処理が、お互いににらみ合ったまま動かなくなるような状況です。デッドロックのための待ち時間とエラーリトライ処理はサーバーリリースの無駄です。ロックのキーをなるべくシンプルにするのは、パフォーマンスに貢献する可能性もあります。
Implicit Lock (暗黙的ロック) は、ビジネスロジックを実装するプログラマーがロックを意識しなくてもよくなるよう、アーキテクチャのメカニズムを担うレイヤーに排他処理を設けるパターンです。単にプログラミングが楽になるだけがそのメリットではありません。確保と解除の対応を確実にしたり、意図せず無駄に重複したロックを確保してしまったりする事故を防ぐことが、Implicit Lock の大事な約目です。
トランザクション範囲の決定を、横断的関心として切り分け、プロクシパターンやアノテーションを使った AOP にするのも Implicit Lock になります。サービスレイヤーを汎化して共通部分でロックを扱うのもそうです。一連のデータ更新をフレームワークが自動的にトランザクション化している場合もあります。とくに Unit Of Work パターンは、最終的な変更差分の反映に暗黙的な排他制御を持つべき箇所の代表です。