• Nice article, thank you!

    I have been reading up on sp_getapplock and wondering if I need to use that for a solution I'm working on. But I'm wondering why I should bother - what's the worst case scenario if I DON'T manage it myself? SQL Server (this project uses 2005) manages concurrency, right? In my case I will have a table with an ID that I need to grab and increment, so obviously it's critical not to have data inconsistency there - but can't I rely on SQL Server to do that by default? I'll have everything in one database, and there will be at most 1000 IDs requested per day.

    You said:

    Using a mutex in Transaction mode doesn't seem particularly useful, as we already have record locks that release at the end of a transaction...

    -- are you referring to what SQL Server does by default, or did you implement something else in addition to manage that?

    Part of my struggle stems from the fact that I don't know how to test that worst case scenario (which for me, would be that two people grab the same ID number somehow, and/or that it doesn't get incremented properly) to know whether I need to handle it differently. I can build unit tests, sure, but how do I know if I successfully got two processes call at the same instant and prove that it is handled properly?

    Thanks -

    Meg