One of the common problem the database developers face in their day to day life is record concurrency issues. Lets try to address that with the help of timestamp data type.
Lets assume that Sarah and Ram are reading a same record. First Ram updates that record with some new data. Later if Sarah also updates the record (mind you she is viewing the old content only still) then it would overwrite the changes made by Ram.
There are two ways of solving this issue they are:
1. Pessimistic Locking
2. Optimistic Locking
Pessimistic Locking: First person who reads the record would put a lock on it so that nobody else can change it until he is done with it. Only when he releases the record the other user can make use of it. This method is not recommended because it might also takes hours or days together for the first person to release his lock due to various reasons.
Optimistic Locking: The record would be locked only when a user wants to modify its content.
SQL Server has a TSEqual (I presume it means TimeStamp Equal) function which compares TimeStamp values in the table and the T-SQL statement. If the timestamp values doesn't match it would throw an error and abort the operation. Let see this in action:
Declare @tStampOriginal TimeStamp
--Here tStamp is a TimeStamp column and TimeStampExample is the name of the table
Select @tStampOriginal = tStamp from TimeStampExample
-- Compares current timestamp value with the original value before updating
Update TimeStampExample Set LastName = 'Kapil' Where LastName = 'Tendulkar' and TSEqual (tStamp, @tStampOriginal)
The above batch of code should execute fine without any issues.
Declare @tStampOriginal TimeStamp
--here tStamp is a TimeStamp column and TimeStampExample is the name of the table
Select @tStampOriginal = tStamp from TimeStampExample
--dummy update statement to change the timestamp value
Update TimeStampExample Set LastName = 'Gandhi' Where LastName = 'Gandhi'
-- Compares current timestamp value with the original value before updating
Update TimeStampExample Set LastName = 'Kapil' Where LastName = 'Tendulkar' and TSEqual (tStamp, @tStampOriginal)
This batch would fail because the @tStampOriginal contains the initial timestamp values which has changed during the dummy update statement.
Lets assume that Sarah and Ram are reading a same record. First Ram updates that record with some new data. Later if Sarah also updates the record (mind you she is viewing the old content only still) then it would overwrite the changes made by Ram.
There are two ways of solving this issue they are:
1. Pessimistic Locking
2. Optimistic Locking
Pessimistic Locking: First person who reads the record would put a lock on it so that nobody else can change it until he is done with it. Only when he releases the record the other user can make use of it. This method is not recommended because it might also takes hours or days together for the first person to release his lock due to various reasons.
Optimistic Locking: The record would be locked only when a user wants to modify its content.
SQL Server has a TSEqual (I presume it means TimeStamp Equal) function which compares TimeStamp values in the table and the T-SQL statement. If the timestamp values doesn't match it would throw an error and abort the operation. Let see this in action:
Declare @tStampOriginal TimeStamp
--Here tStamp is a TimeStamp column and TimeStampExample is the name of the table
Select @tStampOriginal = tStamp from TimeStampExample
-- Compares current timestamp value with the original value before updating
Update TimeStampExample Set LastName = 'Kapil' Where LastName = 'Tendulkar' and TSEqual (tStamp, @tStampOriginal)
The above batch of code should execute fine without any issues.
Declare @tStampOriginal TimeStamp
--here tStamp is a TimeStamp column and TimeStampExample is the name of the table
Select @tStampOriginal = tStamp from TimeStampExample
--dummy update statement to change the timestamp value
Update TimeStampExample Set LastName = 'Gandhi' Where LastName = 'Gandhi'
-- Compares current timestamp value with the original value before updating
Update TimeStampExample Set LastName = 'Kapil' Where LastName = 'Tendulkar' and TSEqual (tStamp, @tStampOriginal)
This batch would fail because the @tStampOriginal contains the initial timestamp values which has changed during the dummy update statement.
Comments