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)?
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