score:0

did you tried this ?

transactionoptions.timeout = transactionmanager.maximumtimeout;

score:1

using (var trans = new transactionscope(
 transactionscopeoption.required, 
    new transactionoptions
    {
        isolationlevel = isolationlevel.readuncommitted
    }
))
{
    // your linq to sql query goes here where you read some data from db
}

while updating tables (inserting, deleting or updating), they become locked, so if you want to read the data, which is not yet commit, so, you can use transaction isolationlevel.readuncommitted to allow dirty reads

score:2

yes, if you start a transaction that manipulates lots of records, and takes a long time to complete, then as a direct result competing operations will be blocked. this is especially true for "serializable" transactions, since they take the most locks (including key-range locks etc). this is the nature of a transaction; it is the i in acid.

options:

  • don't do everything in one huge transaction
  • have your read operations intentionally read past the locks (this is hugely double-edged - can be fine, but can cause big problems - treat with caution) - for example nolock or read uncommitted.
  • on full sql server (not ce), try using snapshot isolation

Related Query