Using locks to manage concurrent access to compound relational docs - MS SQL Server and other servers - turns out not quite trivial

  • my findings on managing concurrency when working with compound 'docs' residing in multiple tables

    http://www.codeproject.com/Articles/1117051/Using-locks-to-manage-concurrent-access-to-compoun

    and why I think Redmond has some work to do...

  • I notice that you bump up system load to find concurrency problems, another method is to introduce "waitfor" statements in your stored procedures in between updating separate parts of your documents and if you give long enough delays you can be very precise in testing multiple processes updating your documents concurrently and seeing how your stuff works with regards to concurrency.

    Really interesting topic!

  • thanks! yeah, you could do it in database too, but.. I don't use stored procs (at least not in this app); and my goal was to figure out proper actions from the client side while firing dumb SQLs, with many client threads - that's the model of the real world app I think.

    Making SQLs/procs include extra stuff (especially Waits) to model concurrency - IMHO it's a distortion of the test case; and brings some doubts about final recipe - will it still work without WAITs and with 100 clients.

    You know, your post is the first feedback I got so far. From any place - codeproject, LinkedIn, here, few other places. Looks like nobody cares about this stuff. That really really surprises me. Not that I feel the article is so good, but the subject?! Feel like I lost connection to this world, what's important and what's not.

    thanks again for your interest!

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply