1
시나리오 :TransactedReceiveScope - 트랜잭션 커밋은 언제 수행됩니까?
우리는 트랜잭션 흐름을 사용하지 않는 클라이언트와 wcf 워크 플로우를 가지고 있습니다. 워크 플로에는 여러 순차적 TransactedReceiveScopes (내용 기반 상관 관계 사용)가 포함되어 있습니다. TransactedReceiveScopes에는 사용자 지정 db 작업이 포함되어 있습니다.
관찰 : 우리가 첫 번째 통화에 대한 SQL 프로파일 러를 실행하면
, 우리는 모든 사용자 정의 DB 호출 및 프로파일 추적에 SaveInstance 호출을 참조하십시오.
SendReply가 TransactedReceiveScope의 맨 끝에 있더라도 트랜잭션이 커밋되기 전에 sendreply가 좋은 10 초가되는 경우가 종종 있습니다.
TimeToPersist 및 TimeToUnload를 0으로 변경해 보았지만 아무 효과가 없습니다. (트레이스는 SaveInstance가 즉시 일어나는 것을 보여 주지만 커밋은 지연되는 것 같습니다.)
질문 :
우리의 관찰 결과가 정확합니까?
언제 트랜잭션이 커밋 되었습니까? 이것은 가비지 수집과 같은 것입니까? 예 : 바쁜 시간이 아닐 때 나중에 다시 실행합니까?
커밋 지연을 제어 할 수있는 방법이 없으며 클라이언트에서 트랜잭션 흐름을 사용하는 유일한 방법입니다 (anc는 클라이언트가 커밋 할 때를 포함하여 지속성을 포함하여 커밋해야 함).
감사합니다. Maurice. 나는 여전히 그것이 당신이 모든 SQL 호출을 saveinstance를 포함하여 프로파일 러에서 볼 수 있다는 것을 알게된다. 그런 다음 그것은 클라이언트로 돌아가지만 커밋되기 전에 여전히 지연이있다. 나는 스케줄러를 읽을 필요가있다. 나는 그것에 대해 언급하지 않았다. 유일한 해결책은 클라이언트가 트랜잭션에 추가 할 자신의 작업이 없더라도 트랜잭션의 커밋을 제어하기 위해 클라이언트의 TransactionFlow를 사용하는 것입니다. – jimasp
이 점을 읽는 또 다른 요점은 클라이언트가 트랜잭션을 워크 플로우에 전달하지 않으면 대부분의 경우 트랜잭션 스페 이스가있는 표준 receive/sendreply 만 필요하다는 것입니다. – jimasp