Table locking for Inserting record

So we have a process where entrants are able to sign-up for a specific offering but there is a max number of spots.  Once the last spot is filled no others can enter that offering and we then create a new offering for others to join.

We have been having issues where 2 people sign up at the exact same time and we end up with 51 spots filled in a 50 spot offering.  I'm assuming we aren't locking the table or something like that.

Currently both person's requests hit the "AddToOffering" stored proc which currently starts a transaction, does a bunch of stuff and commits.  The first thing after the transaction starts is that we check the number of entrants, if there is room, we add them, do a few other things and then commit the transaction and exit the stored proc.    

What we want to achieve is that when both persons concurrently call that stored proc, the first one would put some type of Write Lock on the transaction or at the very least, maybe a table lock on the part of it where we check numbers and add them.  Then the second request waits until the lock is unlocked.  After unlocking, the second request would see that it is full and exit.

We still want the table to be readable for other stored procs though.  We are using sql 2008.  What is the best solution to resolve this issue?  I'm sure its probably basic but we aren't sure if its a system config where we make them serializable, or if the whole transaction has some lock on it, or if each table has a specific write lock and what type of lock that is suppose to be?

Thanks.


LVL 4
kruegersteAsked:
Who is Participating?
 
Scott PletcherSenior DBACommented:
SERIALIZABLE will work but it will cause a lot of waits, even early in the process when you have only 1 or 2 entrants.

You might want to consider serializing only the count of entrants update.  Update the count first in a separate, serialized transaction, and the rest of the modifications with the default isolation level.

For an example, see code below.

You would  need to make sure that if an error occurs during the rest of the tran that you go back and reduce the count.

Just a suggestion as a possibility to maybe reduce locking/contention.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

BEGIN TRAN

SELECT <entrant_count>
FROM tablename
WHERE ...

IF < <max_number>
    UPDATE <entrant_count>

COMMIT TRAN

SET TRANSACTION ISOLATION LEVEL READ COMMITTED 

BEGIN TRAN

...rest of code...

Open in new window

0
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
you will need to do the transaction with isolation level SERIALIZABLE, that should fix that issue .
0
 
kruegersteAuthor Commented:
Thanks for quick response.... two questions though...

Can you post an example or reference to the exact syntax you are referring to?  Is this done in the stored proc?

 Also, how does this command act?  Does only one request get executed at a time, while others basically wait for the current transaction to be committed or aborted?  If so, is this going to be a large performance issue if the transaction contents take a bit to run?  If so, should we commit the part of the transaction that needs the locking and then start of a new transaction for the rest so other requests can get access quicker?

Thanks.
0
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
0
 
kruegersteAuthor Commented:
Thanks ScottPletcher, I was wondering about performance.  Looks like multiple transactions are the way to go.  



0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.