Database Reference
In-Depth Information
GO
UPDATE Production.Product
WITH (UPDLOCK)
SET ListPrice=159.99
WHERE ProductNumber='ST-1401'
The preceding query will take a certain amount of time to update the rows based on
the ProductNumber condition. The locking mode for this query will be
Exclusive
Lock
(
LCK_M_X
).
14. Both the queries on steps 12 and 13 are identified as slow updates for the rows
based on the
ProductNumber='ST-1401'
. Without blocking each process, the
update will succeed after a certain amount of time.
This completes the steps in designing sustainable locking methods to improve concurrency in
the data platform.
How it works...
We started with the
TRANSACTION
ISOLATION
LEVEL
to
SERIALIZABLE
to use the
HOLDLOCK
hint by opening two separate query windows to execute the
SELECT
query.
Executing or setting the isolation level to serializable may not be necessary if we use the
default SQL Server isolation level, which is
READ
COMMITTED
. As per the recipe, the isolation
level will affect the connection until we explicitly change it. Then, we looked into using the
sys.dm_tran_locks
system catalog to obtain locking information for the relevant query
sessions. This will display the information about the time of row or page locks held on the
table that will allow the potential locking mechanisms on transactions to modify the query's
rows while the original transactions remain open. While the data modifications is processing,
whether or not the actual update is committed or rolled back at a later time, using the
SERIALIZABLE isolation allows dirty reads that allows data reads in progress.
Later, we used scripts to see how to use optimistic locking using
SNAPSHOT
ISOLATION
by
referring to the
READ
COMMITTED
option. The first process to hold the row version of
SELECT
and the next process of
UPDATE
statements are executed in different query windows. As
per the settings, the
SELECT
statement will execute without holding any locks due to the
snapshot isolation setting for that session. However, the second session will start updating
the data using exclusive
UPDLOCK
until the update is executed that generates a new version
of row. Another parallel operation of a similar update on another window will capture the
automatic row versioning based on the snapshot isolation mode that is prevented by the first
process from overwriting the update performed by the second process that will prevent any
lost update.
Search WWH ::
Custom Search