게시판 본문 COM / COM+ by VB 6.0 - Read Only

안녕하세요? 송원석, 송원석입니다. ^_^

제 답변이 약간이나마 참고가 되었으면 합니다.

요즘들어 가끔 듣게 되는 질문인데요, COM+ 의 트렌젝션과 기존 방식의 트렌젝션, 즉 스토어드 프로시저나 ADO 의 트렌젝션간의 차이점에 대해서 궁금해 하시는 분들이 많이 계신 것 같습니다.

일단 제 경우에는 이렇게 말씀드리겠습니다. 기술적인 내용뿐만 아니라 유지보수나 관리 등등을 고려하신다면 구성원들이 가장 익숙하고 경험이 있는 방식을 사용하시라고 말입니다. 물론 이것은 순전히 회사의 입장이나 프로젝트의 관리라는 측면에서 말씀드리는 겁니다. ^_^;;;

그러나 기술적으로는 다음과 같은 부분들을 고려해 볼 수 있겠네요. 일단 개발자의 입장에서 가장 중요한 차이점 중 하나는 한 번에 여러 개의 데이타베이스간 트렌젝션이 제어가 가능한지 입니다.

일반적인 경우에는 보통 하나의 ASP 프로그램에서는 하나의 데이타베이스에만 접근을 합니다. 그런데 가끔 보면 하나의 ASP 프로그램안에서 오라클과 MS SQL 2000 과 같이 두 대의 데이타베이스를 동시에 접근하는 경우가 있습니다. 이와 같은 경우 스토어드 프로시저를 사용하거나 ADO 를 사용하여 트렌젝션을 제어한다면 두 개의 데이타베이스에 대해서 각각 따로 트렌젝션을 제어할 수 밖에 없습니다.

반면 COM+ 를 사용하는 경우에는 하나의 트렌젝션으로 두 개의 데이타베이스를 묶는 것이 가능합니다. 따라서 위와 같은 경우에서도 일단 개발자가 요령만 깨우친다면 아주 손쉽게 관리가 가능하죠. 물론 모든 데이타베이스 제품이 COM+ 를 지원하는것은 아닙니다만 유명 제품의 대부분이 지원한다고 보시면 무방할 듯 싶습니다.

그리고 대량의 작업이 요구되거나 상당히 긴 시간, 예를 들어 한 시간 이상의 작업이 요구되는 경우와 같은 경우에는 COM+ 트렌젝션을 사용하실 수 없습니다. 일반적인 웹 환경에서는 사실 이런 경우를 찾아보기 힘들지만 기업 환경에서 월결산 등을 돌리는 경우에는 쉽게 접하게 되는 상황이죠. ^_^;;; 왜 사용할 수 없냐하면 COM+ 는 기본 트렌젝션 타임 아웃이 정확하게는 기억나지 않지만 15 분인가가 한계입니다. 따라서 이를 초과하는 시간동안 트렌젝션을 유지할 수 없습니다.

그러나 어떠한 경우더라도 일단 스토어드 프로시저의 사용은 권장드립니다. 잘 아시겠지만 스토어드 프로시저는 두 번째 실행될 때부터 속도가 증가하며, 동일한 SQL 구문이 코드의 여기저기에서 난립되는 것을 막아줍니다. 차후에 튜닝을 하더라도 적은 노력으로 많은 효과를 기대하실 수 있고 재사용성이 좋습니다.

예를들어 ASP 로 작성된 프로그램을 ASP.NET 으로 다시 마이그레이션 한다고 생각해 보십시요. 스토어드 프로시저를 사용한 경우라면 SQL 구문만큼은 거의 다시 작성할 일이 없을 것입니다. 그 반대의 경우는... 끔찍하죠. ^_^;;;

그리고 다음과 같은 점들도 감안하셔야 합니다, 얼마전 MS 의 RPC 버그가 보안 이슈가 된 적이 있습니다. 그래서 패치도 나왔구요. 그 패치 이후로 COM+ 트렌젝션에 문재가 발생했었습니다. 지금은 해결이 되었는지 잘 모르겠는데 아마 약 한 달도 전의 일이니 아마 해결되었으리라 생각하지만 확인이 필요하실듯 합니다.

그 밖에 속도나 성능 등에 관한 문제점들은 크게 신경쓰실 필요는 없을듯 합니다. 나름대로 다 장단이 있으니까요. 다만 한 가지 원칙만 지키시면 될 듯 합니다. 대부분 기존의 코드를 컴포넌트화 할 때 너무 작은 분량의 코드를 무조건 컴포넌트화 하시는 것은 오히려 속도에 저하를 가져옵니다. 어느정도 규모가 된다 싶은 코드만 컴포넌트화 하시기 바랍니다. 속도를 올리기 위해 작성한 컴포넌트가 초기화 때문에 발목을 잡는 경우가 발생할 수도 있으니까요.

그리고 마지막으로 서적을 너무 믿지는 마십시요. ^_^;;; 서적을 보면 대부분 COM+ 의 장점만 쓰고 단점에 대해서는 얘기를 하지 않는 경우가 많습니다. 예를 들어본다면 VB 로 만든 COM+ 컴포넌트는 오브젝트 풀링이 불가능합니다. 근본적으로 아예 불가능하죠. C++ 로 작성한다고 해도 결코 쉬운일이 아닙니다. 실제로 필요한 코드보다 이를 제어하기 위한 코드가 더 많은 경우도 있습니다. 그럴진데 오브젝트 풀링과 자동 트렌젝션을 동시에 지원하는 컴포넌트는 두 말 할 나위가 없죠. .NET 에서는 이런 한계가 없어지는 등 조금 낳아졌다는 제 개인적인 생각입니다만... 그러나 대부분의 서적 어디에도 이런 부분에 대해서 자세하게 설명을 해주는 서적은 본 적이 없습니다. 어떻게 해결을 해야 하는제 왜 안되는지 등등은 거의 다루지를 않죠. 대부분 어디 구석에 VB 로는 오브젝트 풀링을 지원하는 컴포넌트를 만들수 없다는 한 줄로 끝나고 맙니다. ^_^;;; 저도 처음 공부할 때 무척 당황했었습니다만... 물론 그럼에도 불구하고 COM+ 에는 많은 이점이 있습니다. 그건 사실이죠...

그리고 마지막으로 두 번째 질문은 저도 지금으로서는 답변을 드리기가 곤란하네요. ^_^;;; 저도 .NET 은 막 공부해 나가고 있는 입장이라 어설픈 답변에 오해가 생길까봐 걱정되는군요. 다만 한 가지 확실한 것은 .NET 을 사용할 경우에는 당연히 .NET 컴포넌트를 만드시는 것이 유리하지 않나싶습니다. COM 인터롭은 까다로운 기술일 뿐더러 하나의 계층을 더 가지게 되므로 속도 저하에도 많은 영향을 미칩니다. 차후에 그 부분에 대해서는 다시 말씀을 나눌 수 있는 기회가 있으면 합니다.

감사합니다.