I am using FluentNHibernate, and I have a list of records, mapped to an SQL Server 2008 view. Dirty reads are OK with me, not locking the tables is a priority.
The SQL Query inside the view, does not have any with (nolock), however, I am using the following approach...
using (var txScope = new TransactionScope(TransactionScopeOption.Suppress, new TransactionOptions() { IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted })) { ... The reading of records from the view is done here, through Fluent NHibernate... }
Does setting the isolation level at application layer to read uncommitted, apply with (nolock) to the queries which are generated within that context?
Short answer: No
Long answer:
Just defining the TransactionScope does not define that any read or write will be invoked within a transaction.
To run something within a transaction, you still have to open and commit a transaction!
The
TransactionOptions
of the TransactionScope forTimeout
andIsolationLevel
just define the defaults for any transaction created within the scope without those options explicitly set. Actually the TransactionScope does create a Transaction but it will not be active without opening a new Transaction. Internally this will do some complex stuff, cloning the transaction etc... so lets ignore this...Without a transaction you cannot define the isolation level, any select statement will be run with
IsolationLevel.ReadCommitted
because this is the default of SQL Server.You can also query
session.Transaction.IsActive
to see if a transaction is currently active for the session!Lets have a look at the following code, I put some comments to make it a little bit more clear
You can also watch how SQL Server reacts to those settings by using the SQL Server Profiler.
Just create a new Trace and watch out for the
Audit Login
event, the text of the event will include the isolation level and you can see that it actually does aAudit Login
each time a transaction is created, for example--
Please correct me if any of this information might be wrong, I just figured this out by myself so there might be some potential of failure ;)
I'm not sure why, but the TransactionScope code did not work for me.
I used this code. Starting a new session below makes sure that you don't have an existing transaction already. (There are other ways to do it of course)
In the NHibernate Profiler I could see this: