Database mirroring errors, part two
ilkirk | Monday, December 8, 2008 | 1000(Yes, I’m on vacation. No, I’m not writing this while I’m on vacation - I scheduled it in advance.)
Amongst plenty of other things, Kristine and I spent the week trying to re-create the errors we saw in our production environment. (Giving credit, where credit is due - this was mostly Kristine’s work) To our dismay, we haven’t been able to reproduce the errors!
According to Microsoft Support and to the previously mentioned forum post, the culprit is the sp_getapplock / sp_releaseapplock being used within the database. However, we’ve identified the two stored procedures in the production database that make this call, and we’ve executed them multiple times. The lock procedure have to be executed within a transaction, so we left a few transaction open, and ran our tests to see if this might help - not at all.
We’ve tried with an empty database, we’ve tried with a restore of the original database. We’ve tried with manual tests via SSMS and we’ve tried to create the error with people using the application - absolutely no combination of tricks has given us the results we want / expect. At this point we’re stuck wondering if CU10 will or will not fix our problem.
While I’m away, maybe Kristine will find the magic test that gives us a chance to confirm the fix as well as test the application and then we’ll be ready to move on the patch before the holidays are upon us. Maybe.





