What are the guildelines to detect a possible phatom/s? When will I set the transaction isolation level to SERIALIZABLE ? What will be the best ratio of consistency-concurrency in our database?
Any info will be highly appreciated...
Here is a piece of code I found in an application I'm supporting.
Problem: We're seeing duplicate numbers and I think this code may be the source of it.
At first glance I did not understand how it worked.
It locks a table <begin tran> , updates a number, reads that number, then commits. This code appears to work - it returns the newly added number.
My Question - How? How can this code return a value that is not "Committed" to the database yet. Please critique..... I have an alternate method, please comment on it as well. Thanks for your input.
--THIS IS WHAT I FOUND....
CREATE PROCEDURE sp_UpdateOrderNumber @customer int AS
DECLARE @NewOrderId int,
BEGIN TRAN
UPDATE CUSTOMERS
SET ORDER_NUMBER=ORDER_NUMBER + 1
WHERE COMPANY_ID=@customer
SELECT
If @@ERROR <> 0 OR @@ROWCOUNT <> 1 /* Check for Errors */
Begin
Rollback Tran
Return -999
End
SELECTORDER_NUMBER
FROMCUSTOMERS
WHERECOMPANY_ID=@customer
SELECT
If @@ERROR <> 0 OR @@ROWCOUNT <> 1 /* Check for Errors */
Begin
Rollback Tran
Return -998
End
COMMIT TRAN
My Newly suggested method. Using Implicit transaction.
I believe this is more "concurrency" friendly. Do you?
Begin loop until success
Read Number
Update to Number+ 1 WHERE number is the one I just read
If row was updated, use this new number and set success flag
Loop