LINQ to SQL의 TransactionScope와 Transaction

LINQ to SQL의 TransactionScope와 Transaction

---

LINQ to SQL의 클래식 트랜잭션 패턴의 차이점은 다음과 같습니다.

using(var context = Domain.Instance.GetContext())
{
    try
    {
        context.Connection.Open();
        context.Transaction = context.Connection.BeginTransaction();
        /*code*/
        context.Transaction.Commit();
    }
    catch
    {
        context.Transaction.Rollback();
    }         
}

대 TransactionScope 개체

using (var context = Domain.Instance.GetContext())
using (var scope = new TransactionScope())
{
    try
    {
        /*code*/
        scope.Complete();
    }
    catch
    {
    }
}

---

Linq2SQL은 암시 적 트랜잭션을 사용합니다. 모든 업데이트가 단일 제출 내에서 수행되는 경우 트랜잭션을 직접 처리 할 필요가 없습니다.

문서에서 (강조 내) :

SubmitChanges를 호출하면 LINQ to SQL은 호출이 Transaction 범위에 있는지 또는 Transaction 속성 (IDbTransaction)이 사용자가 시작한 로컬 트랜잭션으로 설정되어 있는지 확인합니다. 두 트랜잭션을 모두 찾지 못하면 LINQ to SQL은 로컬 트랜잭션 (IDbTransaction)을 시작하고이를 사용하여 생성 된 SQL 명령을 실행합니다. 모든 SQL 명령이 성공적으로 완료되면 LINQ to SQL은 로컬 트랜잭션을 커밋하고 반환합니다.

---

를 사용할 때 가지고 TransactionScope있는 try/catch구성이 필요하지 않다는 점에 유의해야합니다 . Complete범위가 종료 될 때 트랜잭션을 커밋하려면 범위 를 호출하기 만하면 됩니다.

즉 TransactionScope, 트랜잭션 상태를 전달할 필요없이 트랜잭션이 필요할 수있는 다른 메서드에 대한 호출을 중첩 할 수 있기 때문에 일반적으로 더 나은 선택입니다.

호출 할 때 BeginTransaction온 DbConnection목적, 당신은 당신이 동일한 트랜잭션에서 다른 작업을 수행 할 경우 트랜잭션 개체 주위를 통과해야하지만, 다른 방법이다.

를 사용 TransactionScope하면 범위가 존재 Transaction하는 한 스레드 의 전류 에 등록되는 모든 것을 처리 하여 코드를 더 깨끗하고 유지 관리 할 수 ​​있습니다.

또한 데이터베이스에 대한 연결뿐만 아니라 트랜잭션에 참여할 수있는 다른 리소스를 사용할 수 있다는 추가 이점이 있습니다.

연결 및 데이터베이스 작업을 최대한 활용해야하는 상황에서는 사용하지 않을 수 있습니다 TransactionScope. 단일 데이터베이스에 대해서도 Distributed Transaction Coordinator가 사용되고 트랜잭션이 분산 트랜잭션으로 전환 될 가능성이 있습니다 (단일 데이터베이스 연결의 경우에도).

이러한 경우 디자인을 방해하는 동안 연결 별 트랜잭션을 전달하는 것을 고려할 수 있습니다.

또는 하나의 리소스를 일관되게 (동일한 스레드에서) 사용한다는 것을 알고 있다면 연결 / 트랜잭션을 참조 카운트하는 클래스를 만들 수 있습니다.

생성시 리소스를 생성하고 개수를 증가시키는 클래스를 생성합니다. 또한 IDisposable(카운트가 0 일 때 감소 / 릴리스 / 커밋 / 중단하는) 구현하고 ThreadStaticAttribute적용된 변수에 카운트를 저장 합니다.

이를 통해 논리 코드에서 트랜잭션 관리를 분리하고 분산 트랜잭션으로 에스컬레이션하는 대신 상당히 효율적으로 단일 리소스를 유지할 수 있습니다.

---

한 가지 큰 차이점 (교훈은 어렵게 배웠습니다) – TransactionScope는 트랜잭션 관리에 MS DTC를 사용합니다.

응용 프로그램이 데이터베이스 트랜잭션 만 관리해야하고 서비스 나 원격 호출이 관련되지 않은 경우 데이터베이스 고유 트랜잭션 (DbTransactions)을 사용하여 MS DTC와 관련된 잠재적 문제를 건너 뛸 수 있습니다.

---

TransactionScope supplies unified management for all resource mangers (SQL server, active directory, file system, …). Moreover, one can write own resource manager: code that detects transaction scope, join its and works exactly as SQL server does: commits or reverts changes like other participants of the transaction. I believed that TransactionScope is mainstream and forgot MS SQL native transactions until failed into huge trap: Windows Server 2008 WEB Edition comes with restricted Distributed Transaction Coordinator Service and Transaction scope works on single computer only. Your ASP.NET application will fail on this system if IIS and SQL server are installed on different computers. Take into account that most public domain providers supply Windows Server WEB edition and SQL server are on separate servers. This means, that you must work with native transactions using explicit transactions management …

---

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.

참고URL : https://stackoverflow.com/questions/542525/transactionscope-vs-transaction-in-linq-to-sql