3

ARGH !!!SubSonic2.2 SharedDbConnectionScope 및 TransactionScope 트랜잭션 혼동

트랜잭션 내에서 SubSonic 쿼리를 래핑 할 수 있도록 SharedDbConnectionScope 및 TransactionScope 개체를 둘러싼 약간의 혼란이있는 것처럼 보입니다.

워드 프로세서 여기 같은 Subsonic: Using SharedDbConnectionScope together with TransactionScope seems to be broken

using(SharedDbConnectionScope scope = new SharedDbConnectionScope()) 
{ 
    using(TransactionScope ts = new TransactionScope()) 
    { 
    // do something 
    ts.Complete(); 
    } 
} 

그리고 다른 문제는 문서가 잘못 두 객체가 다른 방법으로 주위해야한다 제안 ... 사용하여 TransactionScope 감싸 사용 SharedDbConnectionScope를 지정하는 것이 좋습니다 ..

using(TransactionScope ts = new TransactionScope()) 
{ 
    using(SharedDbConnectionScope scope = new SharedDbConnectionScope()) 
    { 
    // do something 
    ts.Complete(); 
    } 
} 

하지만 소스 코드를 살펴보면 훨씬 더 혼란 스럽습니다.

SqlQuery.cs 코드 파일에는 여러 개의 ExecuteTransaction 오버로드가 있습니다. 예를 들어 ...

public static void ExecuteTransaction(List<SqlQuery> queries) 
{ 
    using(SharedDbConnectionScope scope = new SharedDbConnectionScope()) 
    { 
    using(TransactionScope ts = new TransactionScope()) 
    { 
     foreach(SqlQuery q in queries) 
     q.Execute(); 
    } 
    } 
} 

음 ... 흥미 롭 ... 어디 ts.Complete는()를 호출의 ... 이 문서를 일치하지만?

어떻게 트랜잭션을 커밋해야합니까? 내가 볼 수있는 한 항상 롤백 할 것입니다. 그리고 모든 ExecuteTransaction 오버로드에 대해 동일합니다! TransactionWithDtcOffTests.cs 코드에서

그러나 여기 진짜 키커는 ...

은 다른 방법으로 주위 SharedDbConnectionScope 및하여 TransactionScope를 설정 한 것을 제외하고 멋진 테스트가 있습니다!

using(TransactionScope ts = new TransactionScope()) 
{ 
    using(SharedDbConnectionScope connScope = new SharedDbConnectionScope()) 
    { 
    // <snip /> 
    } 
} 

마지막으로

...

누군가가 나에게 줄 수 .. 내가 음속 2.2에 대한 테스트를 실행 할 수있는 기회가 없었어요하지만 난 누군가가 가정 그들은 전달 SubSonic2.2의 트랜잭션을 설정하는 방법에 대한 확실한 답은 무엇입니까? 문서가 실제로 틀렸습니까? ExecuteTransaction 과부하 및 테스트 소스가 실제로 올바른 방식으로 정렬됩니까?

+0

문제를 수행 할 수 없습니다. 여기에 약 3 개가 있습니다. 나는 당신이 좌절감을 느낀다. :) 그러나 나는 당신이 생각하는 것보다 혼란 스럽다고 말할 수 없다. –

+0

SDCS (SharedDbConnectionScope) 및 TS (TransactionScope)의 순서는 혼란 스럽거나 버그가 많은 비트입니다. docs 상태 SDCS는 TS를 래핑합니다. 하지만 그건 효과가없는 것 같습니다. 그래서 그것은 버그입니다. ExecuteTransaction 과부하에는 TS를 래핑하는 SDCS가 있으므로 버그이기도합니다. 어디에서 실제로 과부하가 걸리는지는 알 수 없었지만, 버그에 반대하여 충분히 열심히 보지 않았기 때문에 그럴 수 있습니다.내가 보았던 테스트 코드에는 TSCS가 랩핑되어있다. 그래서 나는 그것이 버그가 아니라고 결론을 내린다. 혼란스러운 비트는 오류의 위치입니다. – BlackMael

+0

SDCS 및 TS의 순서가 SDCS 자체의 오류 또는 오류인지, 문서의 순서가 올바른지 여부. 참고로, 지금은 TS 랩핑을 넣으므로 SDCS가 작동합니다. 여기서 SDCS가 TS를 랩핑하는 것은 필요할 때 롤백하는 측면에서 작동하지 않습니다. – BlackMael

답변

4

SharedConnectionScope (SCS) 블록은 TransactionScope (TS) 블록 내에 있어야합니다. SCS의 목적은 가능하다면 트랜잭션을 MSDTC로 에스컬레이션하는 것을 방지하기 위해서 블록을 사용하는 SC의 블록을 사용하여 TS를 만드는 것은 나에게별로 의미가 없습니다. 어쨌든, 모든 TS 블록은 트랜잭션을 커밋하기 위해 Complete() 호출을 가져야합니다.

0

개인적으로 SQL 2005를 사용할 때 SCS는 TS 안에 있어야하며 SQL 2000 (MSDTC 사용)을 사용할 때는 SC가 TS를 랩핑해야 함을 발견했습니다. 이 도움이 되었기를 바랍니다 ...

관련 문제