为何乐观锁每次更新操作需递增version_id？

Great question! Let's unpack this—your observation about same-session serialization makes total sense, but there are several critical reasons why incrementing the version ID is the standard, reliable approach for optimistic concurrency control:

• Prevent accidental overwrites in the same session
  Even within a single session, bugs or unintended repeats can happen. Suppose you fetch version=1, run an update that succeeds (setting version to 2), then accidentally trigger the same update again using the original version=1. If we didn’t increment the version, this second update would silently overwrite your first change. By incrementing, the second update fails because the version no longer matches—this acts as a safety net against duplicate function calls, unintended retries, or logic errors in your code.

• Guarantee idempotency for retries
  Imagine your service gets a retry request from a client (thanks to a network glitch or timeout). If you reused the same version ID for the same session, the retry would successfully modify the data again, leading to duplicate actions (like double-updating an order status). With version incrementing, the first update changes the version, so the retry’s UPDATE statement (using the old version) fails—this stops unintended side effects from retries, which is crucial for building reliable systems.

• Accurate cross-session conflict detection
  Optimistic locking’s core job is to block conflicting updates from different sessions. Let’s say Session A fetches version=1, Session B also fetches version=1. If Session A updates first and increments the version to 2, Session B’s update (still using version=1) will fail—this is exactly what we want to avoid overwriting Session A’s changes. If we used session-specific IDs instead of incrementing versions, Session B’s update would still succeed, completely skipping the conflict check. Version IDs track the state of the data itself, not just the session, which is essential for detecting actual data conflicts.

• Simplicity and universality
  Incrementing a version column is dead simple to implement (just version=version+1 in your UPDATE statement) and works across all scenarios—whether you’re dealing with single-session logic or multi-service, multi-client access. Using session-based identifiers would require storing session metadata in the database, handling session expiration, and dealing with edge cases like session reuse, which adds unnecessary complexity and limits the solution’s generality.

Your point about same-session statements being serialized is correct—they won’t race against each other—but optimistic locking isn’t just about cross-session races. It’s about ensuring data integrity in all scenarios, including accidental duplicates, retries, and tracking the true state of the data.

内容的提问来源于stack exchange，提问作者choxsword