Is using TransactionScope in Entity Framework queries a good idea?

Question

I've been reading a document from Microsoft's patterns & practices group (Data Access for Highly-Scalable Solutions: Using SQL, NoSQL, and Polyglot Persistence).

In Chapter 3, in the section "Retrieving Data from the SQL Server Database", the authors discuss using Entity Framework to load entities from a database. Here's a bit of their sample code:

using (var context = new PersonContext())
{
    Person person = null;

    using (var transactionScope = this.GetTransactionScope())
    {
        person = context.Persons
            .Include(p => p.Addresses)
            .Include(p => p.CreditCards)
            .Include(p => p.EmailAddresses)
            .Include(p => p.Password)
            .SingleOrDefault(p => p.BusinessEntityId == personId);

        transactionScope.Complete();
    }

    // etc...
}

Note the use of a custom transaction scope via the GetTransactionScope method, implemented in their base context class like so:

public abstract class BaseRepository
{
    private static TransactionOptions transactionOptions = new TransactionOptions()
    {
        IsolationLevel = IsolationLevel.ReadCommitted
    };

    protected virtual TransactionScope GetTransactionScope()
    {
        return new TransactionScope(TransactionScopeOption.Required, transactionOptions);
    }
}

Working with Transactions (EF6 Onwards) on MSDN states:

In all versions of Entity Framework, whenever you execute SaveChanges() to insert, update or delete on the database the framework will wrap that operation in a transaction [...] the isolation level of the transaction is whatever isolation level the database provider considers its default setting. By default, for instance, on SQL Server this is READ COMMITTED. Entity Framework does not wrap queries in a transaction. This default functionality is suitable for a lot of users

The bold emphasis is mine.

My question: is the use of a TransactionScope as shown above overkill, particularly for data reads, when using Entity Framework?

(I realised after posting that the answer to this question might be somewhat opinion-based, sorry about that.)

Answer 1

The question is a little open ended. But may prove useful for people learning about dirty reads. Isolation and EF. And you have read EF Transaction Scope ef6 and we have a clear question.

Generally i would say let EF manage the scope. Beginners dont consider uncommitted reads and it is a good default for EF.

You may have a valid reason to want to control scope. Or need to use an existing transaction. But remains for specialist use.

So now the real question.
Is it good practice to include such defensive programming around isolation.

My view:
Only if it doesnt make the code harder to maintain, and harder to reuse.

Oracle and SQL server have default Read Committed. I would expect so on other DBs.I would therefore conclude, most likely unecessary protection that adds complexity.
I wouldnt add it to my code.

Answer 2

It depends. If you want dirty reads, serializable reads,etc anything other than default isolation level, then you need to wrap you queries inside a transaction scope.