Skip to content

Commit

Permalink
Update concurrency.md (#4724)
Browse files Browse the repository at this point in the history
  • Loading branch information
Qwertyluk committed May 14, 2024
1 parent d4ccf3a commit c12040f
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion entity-framework/core/saving/concurrency.md
Original file line number Diff line number Diff line change
Expand Up @@ -163,7 +163,7 @@ Optimistic concurrency via concurrency tokens isn't the only way to ensure that
One mechanism to ensure consistency is the *repeatable reads* transaction isolation level. In most databases, this level guarantees that a transaction sees data in the database as it was when the transaction started, without being affected by any subsequent concurrent activity. Taking our basic sample from above, when we query for the `Person` in order to update it in some way, the database must make sure no other transactions interfere with that database row until the transaction completes. Depending on your database implementation, this happens in one of two ways:

1. When the row is queried, your transaction takes a shared lock on it. Any external transaction attempting to update the row will block until your transaction completes. This is a form of pessimistic locking, and is implemented by the SQL Server "repeatable read" isolation level.
2. Rather than locking, the database allows the external transaction to update the row, but when your own transaction attempts to do the update it, a "serialization" error will be raised, indicating that a concurrency conflict occurred. This is a form of optimistic locking - not unlike EF's concurrency token feature - and is implemented by the SQL Server snapshot isolation level, as well as by the PostgreSQL repeatable reads isolation level.
2. Rather than locking, the database allows the external transaction to update the row, but when your own transaction attempts to do the update, a "serialization" error will be raised, indicating that a concurrency conflict occurred. This is a form of optimistic locking - not unlike EF's concurrency token feature - and is implemented by the SQL Server snapshot isolation level, as well as by the PostgreSQL repeatable reads isolation level.

Note that the "serializable" isolation level provides the same guarantees as repeatable read (and adds additional ones), so it functions in the same way with respect to the above.

Expand Down

0 comments on commit c12040f

Please sign in to comment.