Windows Forms排他制御の真髄：楽観的ロックとMutexが織りなす「競合なきUI」の設計論
多くの開発者が、Windows Formsの排他制御を「データベースのトランザクション」だけで完結させようとする。しかし、それは甘美な幻想だ。UI層での非同期イベント、ネットワークの切断、そしてプロセス間のメモリ競合。これらを考慮しないシステムは、いずれ必ず「データ不整合」という名の病に蝕まれる。
今日は、VB.NETのアーキテクトとして、現場で絶対に踏んではならない「排他制御の罠」と、それを制するための極限の技術を伝授する。
—
1. データベース層：楽観的排他制御こそが正義である理由
悲観的ロック（`SELECT FOR UPDATE`等）でレコードを占有するのは、Webあるいは高頻度アクセス環境では自殺行為だ。接続が切れた瞬間にデッドロックの温床となる。
我々が採用すべきは、「更新時判定（Optimistic Concurrency）」である。
実装の極意
テーブルに `RowVersion`（または `UpdateTimestamp`）カラムを持たせ、更新クエリでその値を条件に含める。
.net
”’
”’
Public Function UpdateRecord(recordId As Integer, currentVersion As Byte(), newData As DataModel) As Boolean
‘ SQLのWHERE句にVersionを含めるのが鉄則
‘ UPDATE MyTable SET Data = @val, Version = @newVer
‘ WHERE ID = @id AND Version = @currentVersion
Dim rowsAffected As Integer = ExecuteNonQuery(sql, params)
‘ 影響行数が0なら、他者が既に更新済みであると判断する
If rowsAffected = 0 Then
Throw New DBConcurrencyException(“データが既に他者によって更新されています。”)
End If
Return True
End Function
この手法の美点は、DBコネクションを保持し続ける必要がないことだ。VB.NETの`DataTable`や`Entity Framework`においても、このパターンを徹底することで、スケーラビリティを確保できる。
—
2. アプリ間排他：Mutexによる多重起動防止の深淵
一つのPC内で、同じアプリケーションが二つ立ち上がり、同じローカルデータファイルを操作する。これが現場で発生する「怪奇現象」の正体だ。これを防ぐには、Windowsカーネルオブジェクトである`Mutex`を掴むしかない。
Mutexの正しいライフサイクル管理
`Mutex`はアプリケーションの生存期間中、静的に保持する必要がある。`Dispose`のタイミングを誤れば、ゴミ（ハンドル）が残り、二度とアプリが起動しなくなる。
.net
Imports System.Threading
Public Class AppEntryPoint
Private Shared _mutex As Mutex
Public Shared Sub Main()
‘ アプリケーション固有のグローバル識別子
Dim appGuid As String = “Global\MyCompany_CoreSystem_Unique_ID”
Dim createdNew As Boolean
_mutex = New Mutex(True, appGuid, createdNew)
If Not createdNew Then
MessageBox.Show(“既に起動しています。”)
Return
End If
Try
Application.Run(New MainForm())
Finally
‘ 終了時に確実に解放する
If _mutex IsNot Nothing Then
_mutex.ReleaseMutex()
_mutex.Dispose()
End If
End Try
End Sub
End Class
—
3. ファイル操作の極限：FileStreamによる安全なロック
ローカルのiniファイルや設定ファイルを読み書きする際、`File.Open`で安易に開くと、ウイルス対策ソフトや別プロセスとの競合で`IOException`が頻発する。
ここで重要なのは、`FileShare`列挙体の適切な選択である。
.net
”’
”’
Public Sub SafeWrite(filePath As String, content As String)
‘ Read, Writeの共有を禁止し、排他的にアクセスする
Using fs As New FileStream(filePath, FileMode.OpenOrCreate, FileAccess.Write, FileShare.None)
Using sw As New StreamWriter(fs)
sw.Write(content)
End Using
End Sub
‘ usingブロックにより、FileStreamは自動的にCloseされ、ロックが解放される
End Sub
この`FileShare.None`こそが、レガシーなVB.NET環境における「最後の砦」だ。
—
4. アーキテクトからの最終提言
Windows Forms開発において、メモリの解放（`Dispose`）と排他制御は、もはや「作法」ではなく「生存戦略」である。
1. DBは「楽観的」に： トランザクションを長く持たず、バージョンカラムで一致を確認せよ。
2. プロセスは「Mutex」で： OSレベルのカーネルオブジェクトを信頼せよ。
3. ファイルは「FileShare.None」で： 共有違反の例外を恐れず、適切にキャッチしてリトライを実装せよ。
VB.NETは古臭い言語ではない。正しい作法で書かれたコードは、今なおエンタープライズの現場で最も安定して稼働するエンジンだ。諸君のコードが、コンフリクトという名の混沌に打ち勝つことを期待している。
