Concurrency defines how the system handles the "Lost Update" problem. Suppose two users open the same Edit screen. User A saves first. Then User B saves. Does User B overwrite User A's changes? Your choice of strategy determines the user experience.
You "Lock" the row the moment the user starts editing. No one else can even read it. This is very safe but results in a terrible user experience (locked screens) and low scalability.
This is the industry standard for web apps. You don't lock anything. When the user saves, you check if the data has changed since they opened the screen. We do this in SQL Server using a RowVersion (or timestamp) column.
UPDATE Users SET Email = @NewEmail
WHERE Id = @Id AND RowVersion = @OldRowVersion
IF @@ROWCOUNT = 0 THROW 50000, 'Concurrency Error: Data has changed!', 1;Q: "When would I ever use Pessimistic concurrency in a modern app?"
Architect Answer: "You use it for extremely high-contention, low-latency scenarios where the 'Cost of Failure' is high. For example, a **Stock Exchange** or a **Seat Booking** system. In these cases, it is better to tell the user 'This seat is currently being booked' (Pessimistic) rather than letting them fill out a 5-page form only to tell them 'Sorry, someone else grabbed it 1 second ago' (Optimistic)."