XA 갖고 흔히 고민하는 것은, "어떤 것까지를 XA로 짜느냐"입니다...
그래서, 처음에 표준을 제안하는 컨설턴트 엔지니어의 취향 또는 판단에 따라서 <DML을 포함하는 모든 서비스는 XA로 한다>는 경우도 있고, 제가 항상 주장하는 "XA 최소주의"처럼, 웬만하면 nonXA로 짜게 하는 경우도 있습니다.
그것은 XA 인터페이스의 특징을 얼마나, 어떻게 사용 할것인지.. 아니면 사용 안할 것인지로 결정을 해야 합니다. 그러자면 먼저 XA를 쓰는 AP가 어떻게 돌아가는지 이해 할 필요가 있겠군요...
1) XA와 nonXA의 개요
XA를 사용하지 않는.. nonXA라고 표현하는 유형의 AP는 AP에서 RM(=Resource Manager ; DBMS)에 직접 연결합니다. 물론 여기에서도 트랜젝션 관리는 가능합니다만, 이 트랜젝션이란게 결국 '서비스' 범위 안에서만 관리가 되겠지요. DBMS의 기본기능에 의한 관리니까요..
이걸로도 관리는 됩니다. 하지만, transaction의 처리 상황을 client 에서는 전혀 어찌 control을 한다거나 coordinating을 한다거나 할 수가 없다는 점은 nonXA의 어쩔 수 없는 한계이지요. 그러다보니, 여러회의 service call을 통틀어 관리해야 한다거나 하는 것은 어찌할 도리가 없는 것이 nonXA 입니다.
뭐 그래서 TUXEDO/TMAX를 안쓴다면 업무 자체를 한 서비스에 여러 단계의 SQL을 넣어서 1 call로 처리하도록 설계 하겠죠. 하지만 이건 비효율적입니다.
그래서 XA라는 놈을 쓰는데.. XA는... RM에 직접 맺어야 할 세션을 TM으로 가서 맺습니다. TM은 Transaction Manager라는 entity인데 보통 'TMS'라고 부르는 서버 프로세스입니다. 이 녀석이 DBMS보다 한 꺼풀 위에서 transaction 처리를 맡습니다. 물론 low-level한 수준은 아니지만 SQL문 단위가 아닌 service call 단위로 transaction을 관리하지요...
그리고 xa 특유의 동작을 위해 TM이 RM과 연결하여 communication을 하는데, 이것은 AP 개발자가 신경 쓸 영역은 아니지요.
여기서 AP와 TM 사이의 인터페이스를 TX 인터페이스라고 부르고....
TM과 RM사이의 인터페이스를 XA 인터페이스라고 부르는 것입니다.
차이가 있죠? nonXA는 AP와 DBMS가 SQL이라는 일종의 'RM-AP interface'로 붙고..
XA는 AP와 DBMS가 TMS를 매개로 TX->XA의 두 가지 인터페이스를 거쳐서 붙네요.
그만큼 overhead도 있고 performance delay도 있을 수 있다는 얘기가 됩니다.
그래서.... 사실 모든 AP를 XA로 짜는 것도 가능은 하지만.. 그렇게 하지 않는 것입니다.
(사실 XA call은 GTT를 소모하므로 MAXGTT 및 TLOG등의 size도 키워야 하는 점도 있구요... ^^)
2) XA와 nonXA의 장단점.
XA를 써서 좋은 점이 뭘까요? 그렇죠... 가장 먼저 나오는게 global transaction.. GT 입니다. 한 클라이언트에서 서로다른 여러개의 service를 왕창 call 해서 그것을 transaction 으로 묶고 한꺼번에 '모 아니면 도' 시스템. 영어로는 'all-or-nothing' 이라고 부르는 방식으로 처리를 할 수 있습니다. (transaction 관리의 기본은 '모 아니면 도'잖아요.. ^^)
즉, client에서 transaction coordinating을 할 수 있다는 것이죠.
그래서 좋은 점은? 네에.. XA 안쓰면... 한 서비스 안에 "이렇게 하고 저렇게 하고 그렇게 해서 요렇게 해라.." 라는 로직을 모두 넣어놓고, 그걸 commit 하든 rollback 하든 해야 하지만... XA를 쓰면 "이렇게"를 하나 짜고.. "저렇게"를 하나 짜고.. "그렇게"도 따로 짜고.. "요렇게"도 따로 짤 수 있습니다.... XA를 안쓴다면 만일 "저렇게 하고 요렇게 한 다음에 이렇게 하자"는 프로그램을 짜야 한다고 해도, 뭐 생판 첨부터 따로 짜야 하지만, XA를 사용하면 그냥 순서만 바꿔서 call 하면 되겠죠? 이것이 down sizing의 묘미잖아요... 이것이 성능향상도 가져올 수 있구요.
나쁜점은 아까도 얘기했지만 느려질 수 있다는거.. 부하가 쫌 간다는거...
보통 성능을 재는 단위는 TPS를 씁니다. Transactions Per Second 인데, 1초에 몇 트랜젝션을 처리하느냐 하는 것이죠... 그게 약 25% 정도가 감소한다는 것이 정설입니다. 좀 크죠? ^^
3) 그러면 도대체 어떤 놈을 XA로 해야 하는가?
XA로 해야 하는 서비스는 어떤 것일까요? 대충 이렇게 정리하고 싶군요..
- global transaction에 묶여야 하는 서비스.
- client가 transaction coordinator가 되는 경우. (= 클라이언트가 커밋해야 하는 경우)
- timeout 관리가 필요한 경우.
이렇게 나눠볼 수 있겠습니다. 어떻게 보면 여기에 해당되는 서비스는 많지 않을 수 있지요.. 그게 정상입니다. 명심해야 할 것은, XA 인터페이스를 통하면 25%의 속도저하가 있습니다. 25%라는 숫자가 별로 크게 다가오지 않는다면야 할 말이 없지만.. 흐..
그렇다면, GT에 묶이지도 않고, 굳이 클라이언트에서 확인빨 때려서 커밋할 필요도 없고, 속도도 빨라서 timeout 관리도 필요 없고 단발성이고.. 뭐 이러면 이건 nonXA로 해서 서비스 안에 일일이 EXEC SQL COMMIT WORK; 이니 하는 문장을 넣어야 하느냐?
맞습니다. 그게 낫다는 것입니다. 하지만 저 commit 문장을 진짜로 넣을지 말지는 표준안의 process frame과 API wrapping을 잘 하셔서, 개발자 입장에서는 아무 생각없이 짜더라도 처리가 되도록 하는 것이 좋겠지요. 왜냐? 나중에라도 XA 서비스로 전환해야 한다면 손쉽게 전환해야 하기 때문이기도 합니다. ^^
출처 :
http://ask.nate.com/qna/view.html?n=6077395
