We have a complex Stored Procedure which first does INSERTS and then does UPDATES in a particular row. Ideally after completion of this request if user 2 hits the same SP and some SELECTS have to happen instead of UPDATES.
In case more than one requests come at the same time doing the first oepration, then we naturally get deadlocks on that UPDATE.
We are thinking of implementing WAITFOR such that the SP first sets a flag in a global temp table before starting and if a second request comes, it does waitfor some time to try again, so that after say 10 seconds, it can try again and if it sees that the update is done, it can skip completely to SELECT logic. This way we feel no user will get deadlock, after after say 5-10 seconds will get the results returned ultimately.
Is using WAITFOR like this fine or a DB architecture issue for some possible future issue?
This is a very risky idea, the database already has plenty of facilities to allow you to concurrently insert and update records. You can use transactions and hints to reduce the risk of deadlocks. Often improper indexing can lead to a large amount of deadlocks.
Implementing a spinlock in a SQL proc is something that will generally go wrong.
I blogged about some patterns you can use a while back: http://samsaffron.com/archive/2008/08/27/Deadlocked+