Concurrency issue for SQL server transactions for a table - sql-server

Question

I have inherited a system where there is a table X where points are allocated to users. Below is an example of how this looks like -
When a row is added the NewBalance is the actual total balance for the user.
How this is done is in a transaction (I am attaching values which are dynamically passed):
BEGIN
DECLARE #userId uniqueidentifier = 'DA04C99F-575A-434F-BD69-05F2C111360E'
DECLARE #oldBalance int
DECLARE #newPoints int = 25
SELECT TOP 1 #oldBalance = NewBalance FROM X WHERE UserId = ORDER BY [Date]
DESC
INSERT INTO X (UserId, Date, Value, NewBalance) VALUES (#userId,
SYSDATETIMEOFFSET(), #newPoints, #oldBalance + #newPoints)
END
The above piece of code can be called from multiple modules to add points each of which are running in different isolation levels. It is also possible that this gets called concurrently from 2 different modules - so we end up with something like this -
Obviously 2 different transactions read the same row while fetching the initial #oldBalance and then each added to it resulting in the problem.
We are thinking of making all modules that call this piece of code to run under Serializable isolation level. But we are having trouble replicating the problem in lower environments and so there is no realistic way to test.
Also, from what I understand irrespective of isolation level the SELECT TOP 1 will always place a shared lock on the row so it can be read by other transactions.
Any tips or reading material to solve the problem would be appreciated.

Answer 1

Depending on how much changeability you have over the table structure itself, you could do as others have suggested restrict it to a single row to show only the current row and then use a lock on the table.
You could also implement a counter type for each of the unique records so the current iteration of data inserted is always sequential because you're checking if it's been updated since you started your update.
I have added a simple way of doing the update using a procedure rather than just inserting. I am not aware of your application or database, but if you are able to read the output and store the balance to add you are able to implement a retry until the values match and it enables the insert.
CREATE TABLE X (UserId UniqueIdentifier, Date DATETIME, Value INT, NewBalance INT)
INSERT INTO X VALUES (NEWID(), GETUTCDATE(),10,10)
SELECT * FROM X
BEGIN
DECLARE #userId uniqueidentifier = '5396C445-8AC1-4B46-8E25-A416059D7976'
DECLARE #oldBalance int
DECLARE #newPoints int = 25
SELECT TOP 1 #oldBalance = NewBalance FROM X WHERE UserId = #userId ORDER BY [Date] DESC
EXEC dbo.usp_Update_X #userId, #oldBalance, #newPoints
END
CREATE PROCEDURE dbo.usp_Update_X
(
#UserID UniqueIdentifier
,#OldBalance INT
,#newPoints INT
)
AS
IF #OldBalance = (SELECT TOP 1 NewBalance FROM X WHERE UserId = #UserID ORDER BY Date DESC)
BEGIN
INSERT INTO X (UserId, Date, Value, NewBalance) VALUES (#userId,
SYSDATETIMEOFFSET(), #newPoints, #oldBalance + #newPoints)
Print 'Inserted Successfully'
END
ELSE
Print 'Changed - Get Balance Again'
GO
Once something like this has been implemented, you could then periodically check to ensure the values go in the correct order
SELECT UserId, Date, NewBalance, Value, SUM(Value) OVER (Partition By UserId ORDER BY Date ASC) AS NewBalanceCheck
FROM X