Read lock in Linq2SQL - linq-to-sql

Question

I have a classic balance update concurrency situation:
using (var context = GenerateContext())
{
var account = context.Accounts.First(x => x.id == accountId);
var balanceBefore = account.balance;
// ... do some other stuff ...
account.balance = balanceBefore + depositAmount;
context.SubmitChanges();
}
I would like to lock the whole table for reads/writes during this update.
Can it be done with Linq2SQL?
Edit:
So I tried the following, which does lock the table during the transaction, but it doesn't preform the update - the balance never changes.
using (var context = GenerateContext())
{
context.Connection.Open();
context.Transaction = context.Connection.BeginTransaction(IsolationLevel.Serializable);
var account = context.ExecuteQuery<Account>("SELECT TOP 1 * FROM [Account] WHERE [Id] = 10 WITH (TABLOCKX)").First();
var balanceBefore = account.balance;
// ... do some other stuff ...
account.balance = balanceBefore + depositAmount;
context.SubmitChanges();
}
What am I doing wrong?

Answer 1

To start with, balance updates are best handled on the back end:
UPDATE Account
OUTPUT inserted.*
SET balance += #deposit
WHERE ID = #id;
But lets consider you can only code logic on the client. You should always use optimistic concurrency instead. The benefits of optimistic concurrency under load are too big to dismiss. While pessimistic concurrency is easier to code (as there is no update failure due to concurrency to handle), pessimistic concurrency performs poorly under load.
Linq2SQL supports optimistic concurrency, see Optimistic Concurrency: Overview. The key is the Updatecheck attribute. However, handling concurrency violations in the app is more tricky than just detecting them, but the topic is entirely dependent on the actual app logic.
For the extremely rare case when Optimistic concurrency is not appropriate, the first solution to try is ... still optimistic concurrency, but augmented with application locks.
Even if, say, the world would come to end if you used optimistic concurrency and you decide that you absolutely must take the pessimistic route, use (UPDLOCK, ROWLOCK) and have an appropriate index on ID.

Answer 2

Okay, I managed to make it work.
I had to encapsulate everything with a TransactionScope and apply TransactionOptions with isolation level to the transaction scope.
It now looks like this:
using (var context = GenerateContext())
{
var txnOptions = new TransactionOptions();
txnOptions.IsolationLevel = System.Transactions.IsolationLevel.Serializable;
using (var txnScope = new TransactionScope(TransactionScopeOption.Required, txnOptions))
{
var account = context.ExecuteQuery<Account>("SELECT TOP 1 * FROM [Account] WITH (TABLOCKX) WHERE [Id] = 10").First();
var balanceBefore = account.balance;
// ... do some other stuff ...
account.balance = balanceBefore + depositAmount;
context.SubmitChanges();
txnScope.Complete();
}
}