I have first experience of parallel programming of code which actively works with relational database. I find it interesting to combine .NET parallel programming primitives with database locks/transactions and I'm interested in articles on this topic. Could you please advice some (.NET is optional)?

  • Your question is way too broad. A database engine is inherently concurrent and takes parallel requests. You are more likely to bollix the client code and cause race conditions on the database
    – gbn
    Feb 20, 2011 at 11:22

1 Answer 1


Not answering your question but...

IMO that's a mistake, unfortunately you see this kind of thing more and more often where code getting intermingled with database which leads to maintainance and performance problems.

There are some instances where it might be warranted, like doing some quick-n-dirty small application where you run linq-2-sql.

However in general I'm a firm believer that having a layer of abstraction and separation between the database and the code. The programmer shouldn't need to know and worry much about the inner working of the database but have a set of stored procedures to work against. Having the correct set of sp's might be a point of cooperation though.

Likewise the database designer/programmer shouldn't need to worry about changing around fields, tables or optimizing performance in the database without having to worry breaking something the programmer has done directly against the database instead of a sp.

Not having a clear separation of layers in their architecture is one of the most common and most expensive mistake I see over and over done in big projects.

In your case, without knowing more, you should probably have the database deliver a dataset and work on it in parallel. Running concurrent queries against data that is not in-memory is typically not good performance anyways

  • 2
    If you're not answering the OPs question, then you should maybe find a more suitable question for your answer? Feb 20, 2011 at 12:25
  • Sometimes it's good to answer the question they should be asking "is this a good idea?" ;)
    – Homde
    Feb 20, 2011 at 12:29
  • I have seen the stored procedures advice before, and it strikes me as the wrong place to separate things. A much better place for that abstraction layer is in the ORM the application uses, and not within the database.
    – btilly
    Feb 20, 2011 at 14:25
  • 1
    I realize that ORM vs SP's is largely a matter of taste and opinion. Nevertheless it strikes me as ORM's is programmers answers to prefer code over SQL (in the same regards as having "everything" in the database is DBA's answers to prefering SQL) and you get a dependency between the database and the ORM-layer. Also it makes it harder for the DBA and programmer to optimize separately since you have no abstraction between the two.
    – Homde
    Feb 20, 2011 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.