With optimistic, or positive, concurrency, the record is not locked during the edit phase. Instead, the record is locked for a split second just before the new changes are committed to the database and immediately unlocked after the changes have been made. Optimistic concurrency is generally used in environments with a low contention for data, such as web applications, where there are minimal chances of two users needing to update a record in close proximity to each other.
Of course, with optimistic concurrency handling, it becomes incumbent upon every requestor to check if the record has been updated before they commit any changes. There are several techniques for testing for an optimistic concurrency violation. One involves including a timestamp column in the table. In a test for optimistic concurrency violations, the Update Date and Time are compared with the original value returned when the edit began. If they are the same, the new changes are committed to the database. If the Update Date and Time have changed, because another user may have updated the record, the second user to have completed the editing receives an error.