title: Should I avoid using sp_getAppLock?
body: <p>I have a stored procedure, and I want to ensure it cannot be executed concurrently.</p>
  <p>My (multi-threaded) application does all necessary work on the underlying table via this stored procedure.</p>
  <p>IMO, locking the table itself is an unnecessarily drastic action to take, and so when I found out about <code>sp_GetAppLock</code>, which essentially enforces a critical section, this sounded ideal.</p>
  <p>My plan was to encase the stored procedure in a transaction and to set up <code>spGetAppLock</code> with transaction scope. The code was written and tested successfully.</p>
  <p>The code has now been put forward for review and I have been told that I should not call this function. However when asking the obvious question &quot;why not?&quot;, the only reasons I am getting are highly subjective, to do with any form of locking being complicated.</p>
  <p>I don't necessarily buy this, but I was wondering whether anyone had any <em>objective</em> reasons why I should avoid this construct. Like I say, given my circumstances a critical section sounds an ideal approach to me.</p>
  <p><strong>Further info:</strong> An application sits on top of this with 2 threads T1 and T2. Each thread is waiting for a different message M1 and M2. The business logic involved says that processing can only happen once both M1 and M2 have arrived. The stored procedure logs that Mx has arrived (insert) and then checks whether My is present (select). The built-in locking is fine to make sure the inserts happen serially. But the selects need to happen serially too and I think I need to do something over and above the built-in functionality here.</p>
  <p>Just for clarity, I want the &quot;processing&quot; to happen exactly once. So I can't afford for the stored procedure to return either false positives or false negatives. I'm worried that if the stored proc runs twice in very quick succession, then both &quot;selects&quot; might return data which indicates that it is appropriate to perform processing.</p>