TransactionScope vs Transaction in LINQ to SQL?

Linq2SQL will use an implicit transaction. If all of your updates are done within a single Submit, you may not need to handle the transaction yourself.

Linq2SQL will use an implicit transaction. If all of your updates are done within a single Submit, you may not need to handle the transaction yourself. From the documentation (emphasis mine): When you call SubmitChanges, LINQ to SQL checks to see whether the call is in the scope of a Transaction or if the Transaction property (IDbTransaction) is set to a user-started local transaction.

If it finds neither transaction, LINQ to SQL starts a local transaction (IDbTransaction) and uses it to execute the generated SQL commands. When all SQL commands have been successfully completed, LINQ to SQL commits the local transaction and returns.

3 If you need to submit something with cyclical properties (common), you hit a bug in LINQ to SQL that requires you to remove one part of each 2-way reference, submit, repair the 2-way references, and submit again. You need to wrap all this in your own transaction to do so. It's a common need, so "Don't worry about it" isn't the best answer.

– Chris Moschini Jul 12 at 14:56.

It should be noted that when using the TransactionScope there is no need for the try/catch construct you have. You simply have to call Complete on the scope in order to commit the transaction when the scope is exited. That being said, TransactionScope is usually a better choice because it allows you to nest calls to other methods that might require a transaction without you having to pass the transaction state around.

When calling BeginTransaction on the DbConnection object, you have to pass that transaction object around if you want to perform other operations in the same transaction, but in a different method. With TransactionScope, as long as the scope exists, it will handle everything that registers with the current Transaction on the thread, making your code cleaner, and more maintainable. On top of that, you have the added benefit of being able to use other resources that can participate in transactions, not just the connection to the database.

I believe they are fundamentally the same that the TransactionScope class will interface with the ADO. NET underlying connection to create and either commit or rollback the transaction. That the TransactionScope class was just created to make working with ADO.NET persistence cleaner.

Edit: Clarifying my statement with regards to casperOne's addition it is the TransactionScope that will create the transaction and the connection will then see the transaction that was created by the TransactionScope and use it since it's available to it.

Christ Marisic: It's the other way around. The connection looks for the presence of a Transaction for the current thread, which would be created by TransactionScope. If there is one, then it enlists with the Transaction.

The coordinator will then tell the connection to commit or rollback. – casperOne? Feb 12 '09 at 18:42.

One big difference (lesson learnt the hard way) – TransactionScope uses MS DTC for transaction management. If your application has to manage database transaction only, and no services or remote calls are involved, you can skip the potential issues related to MS DTC by using transaction native to databases (DbTransactions).

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.