Entity Framework: controlling db connection and defining your own transaction

Question

I want to find a way to manage the EF connection and transaction under the db base, to make sure that my application uses only one connection at a time per transaction (I will need to support both Oracle and SQL Server).

I found this one that contains many recommendations, but calls (like all the other articles that I read) TransactionScope . Well, I would like to stay away from TransactionScope , if possible ...

Can I get a solution for this playback only with pure DbConnection and DbTransaction or is it simply impossible or wrong?

Moreover, I found this article here , indicating in the section:

" Indication of own transaction "

Just as you can override the default behavior with a connection, you can also control the functionality of transactions. If you explicitly create your own transaction, SaveChanges will not create a DbTransaction. You will not, however, create a System.Common.DbTransaction. Instead, when creating your own transactions, you need to use the System.Transaction.TransactionScope Object.

But there is no explanation ...

I am using Entity Framework 5.0. Could you help me understand in order to choose the right one for my application? It would be ideal to show me good patterns of use.

Thanks in advance!

Note. I plan this because of the escalation of transactions in DTC for the Oracle data provider.

Answer 1

Entity Framework 6 has two features that can help with this:

• Explicit transaction support
• Ability to create DbContext from DbConnection.

If you want to use EF5, you will need to use TransactionScope:

 var context = new MyContext(); using (var transaction = new TransactionScope()) { MyItem item = new MyItem(); context.Items.Add(item); context.SaveChanges(); item.Name = "Edited name"; context.SaveChanges(); transaction.Complete(); } 

As mentioned in a related article, you will need to reference System.Transactions to get TransactionScope .

Answer 2

Entity Framework supports its own transaction, which is sufficient. However, this gives you the flexibility to commit or cancel changes to a transaction. If you did not call the SaveChanges () method, it will cancel the transaction. Also, if you use the same DbContext for many transactions, then it will use the same connection. If you use two or more DbContext at the same time, then it will use separate connections, which are the ideal situation. Here is a very important point that I would like to make is that to implement my own transaction would be a waste of Entity Framework technology. If you want to do this, I would suggest using your own database implementation in the traditional way.