Database Reference
In-Depth Information
Figure 21-6.
Snapshot isolation level and writers behavior (2)
In either case, Session 1 commits the transaction as the next step. At this point, the exclusive (X) lock on the row
is released. If Session 2 tries to read that row, it would still use the version from the version store because it was the last
committed version at the time that Session 2 transaction started. Nevertheless, if Session 2 tries to modify that row,
it would generate the 3960 error and rollback the transaction, as shown in Figure
21-7
.
Figure 21-7.
Error 3960
■
Tip
You can implement retry logic with trY/CatCh statements to handle the 3960 error.
You need to keep this behavior in mind when you are updating the data in SNAPSHOT isolation level in a
system with volatile data. If other sessions update the rows that you are modifying after the transaction is started,
you would end up with this error even if you did not access those rows before the update. One of the possible
workarounds is using
READCOMMITTED
or other non-optimistic isolation level table hints as part of the update
statement, as shown in Listing 21-1.
