트랜젝션과 잠금의 마지막 이야기는 데드락 입니다.

앞에서 언급을 해 드렸지만...

데드락은..

사용자1과 사용자 2가 있다고 가정해 보겠습니다.

그리고 테이블A와 테이블B가 있다고 가정해 보지요..

사용자1은 트랜젝션 처리를

테이블A -> 테이블B -> 작업후 완료.. 이렇게 처리를 하며..

사용자2는 트랜젝션 처리를

테이블B -> 테이블A -> 작업후 완료 이렇게 처리를 합니다.

이럴 경우... 사용자1이 테이블A를 잡을때, 동시에 사용자2가 테이블 테이블B를 

해들했다고 가정한다면.. 각각의 처리들은 모두 다음 개체를 사용하려고

서로 노려만 보고 있는 것입니다. 이런 상황을 교착상태라고 하며..

이 데드락은 역시나 SQL서버가 중재를 해서.. 하나의 프로세스를 Victim(희생양)으로

해 버리는 식으로 처리합니다.

이렇게 데드락이 걸리는 상황을 간략히 말씀 드렸구요..

이 데드락을 피하는 방법은 잘 구성된 솔루션 개발 계획입니다.

예를들어..

회사내부에 제품 삭제를 하기 위한 프로세스가 있다면?

1. A테이블 수정

2. B테이블 수정

3. C테이블에서 삭제

4. 제품 삭제

이렇게 운용이 될 겁니다.

그리고.. 사용자 삭제 프로세스라는 녀석이 있다면?

1. Y테이블 삭제

2. X테이블 삭제

3. C테이블 삭제

4. B테이블 삭제

5. A테이블 삭제

6. 사용자 삭제

이런 프로세스로 생각하실지 모르나..

보시는 바와 같이..

프로세스 수행 방식이 서로 엇갈리는 - 데드락 발생 가능성이 높은 프로세스

처리 방식이 되었습니다.

이럴때.. 하나를 바꿔 주시면 됩니다.

저는 사용자 삭제 프로세스를..

1. A테이블삭제

2. B테이블 삭제

3. C테이블 삭제

4. X테이블 삭제

5. Y테이블 삭제

이렇게 순서를 바꾼다면? 프로세스 수행중에.. 트랜젝션 처리가 교착될 염려는

없겠지요. 이렇게 바꾸는 것을.. 시리얼하게 바꾼다고 보통이야기 합니다.

하지만.. 저렇게 프로세스 흐름을 바꾸기란 정말 쉬운일이 아닙니다.

해보신분은 아실 겁니다.

개나소나 다~ 참조하는 user테이블의 한 계정을 지우려면?

이곳 저곳의 참조하는 객체를 먼저 지운후 user테이블을 지워야 하지요.

저는 개인적으로 30개 정도의 테이블에서 삭제후 user테이블을 지우던 기억이 납니다.-_-

저렇게 바꿀수가 없을것 같다구요?

말도 안될것 같지만 가능합니다.

저장 프로시져와 같은 프로그래밍 로직으로.. 순차를 정해..

정 먼저 지울 녀석이 있다고 해도.. 적절하게.. 변수로 키값을 select로 받아만

두고 변수에 저장후 나중에 지우거나.. 이렇게 처리가 분명 가능합니다.

그리고 수정이 걸리는 부분은 저렇게 처리가 가능하지요.

막을 수 있는 근본적인 방법?

간단합니다. 프로젝트를 기획 하시면서.. 컴퍼넌트 디자인 프로세스나.. 구현 단계에서

해당하는 테이블 접근 순서를 문서화 하는 것입니다.

그리고 또한 트랜젝션 처리 모듈은 따로 관리를 해서..

트랜젝션 처리 순서 모듈을 문서화 해두고.. A저장 프로시져가.. L-> M -> N 이라고

접근을 한다.. 그러나 B저장 프로시져를 생성할때도 J -> K -> L 이라고 개체를 접근하게

해야 겠다는.. 기준이 남도록 적절한 문서화를 해 두시면..

대형 프로젝트로 여러명이 나누어 개발을 할 경우라도 저러한 교착상태나

블러킹을 최소화 하실 수 있게 되는 것입니다.

만약 데드락이 발생한다면?

바로! 해당 어플리케이션 모듈의 디버깅을 들어가시면 되겠지요. ^_^

데드락 샘플을 보시기 보다는.. 이렇게 개발단계의 시리얼라이즈한 개체 핸들 순서의

문서화가 더 중요한 부분이기 때문에.. 이정도로.. 데드락 처리를 마치도록 하겠습니다.

오래간만에 강좌를 적으니.. 조금 어깨가 뻐근~~ -_-;; 하네요..

이제 약간 여유가 생겼으니.. 빠르게 강좌 마무리에 들어 가도록 해야겠군요. ^_^

샘플이 이번에는 별로 없어 실망이라구요? ^_^

제가 잠금과 데드락이나(사실 거의 발생 안합니다. - 이름만 무서운 데드락일 뿐입니다.)

이런 문제를 접하면서.. 이 장에서 설명드린 내용 이상의 내용은 거의 없습니다.

나중에 자신이 필요하다면.. 추가적으로 공부를 진행하시면 도움 되겠지요. ^_^

자 수고하셨구요.. 혹시나 이 강좌의 내용에 문제가 발견 된다면? 바로 메일이나..

게시판에 글을 남겨 주시길 바랍니다. ^_^

그럼 이만.

11. 트랜젝션과 잠금처리 - 7. 데드락(Deadlock)처리 문서의 끝입니다.