1. 기본사항
Ø Multithreaed/Multicontexted 응용 프로그램에 대한 지원
Ø BEA 턱시도는 다음과 같은 경우에만 해당 기능을 지원한다.
|
① 커널 레벨 쓰레트 패키지 지원(유저 레벨 쓰레트 패키지은 지원하지 않음) ② C 언어로 작성된 Multithreaded 응용 프로그램 지원(COBOL 언어는 지원하지 않음) ③ Multicontexted 응용 프로그램은 C 언어 또는 COBOL 언어 둘다 지원 |
권고사항) 여러분의 OS 가 다른 쓰레트 함수뿐만 아니라, POSIX 쓰레트 함수까지도 지원한다면
우리는 POSIX 쓰레드 함수를 사용하기를 권고한다. 왜냐하면, 그것은 나중에 다른
플랫폼에 이식하는 데 월씬 더 쉬운 코드를 만들도록 하기 때문이다.
참고설명) 여러분의 플랫폼이 커널 레벨 쓰레드 패키지, C 함수 또는 POSIX 함수를 지원하는지를
알아보려면 ‘Installing the BEA Tuxedo System’ 에 있는 Platform Data Sheets
에서 여러분의 OS 시스템의 Data Sheet 를 참조하면 된다.
Ø Multithreaded/Multicontexted 응용 프로그렘에서 플랫폼 고려사항
|
대부분의 플랫폼은 Multithreaded/Multicontexted 응용 프로그램을 위해 독특한 필요사항을 가지고 있다. ‘installing the BEA Tuxedo System’ 의 Platform Data Sheets 는 이러한 플랫폼별 필요사 항을 보여준다. 여러분의 플랫폼에서 필요한 것이 무엇인지릉 알려면, 해당 Sheet 에서 찾아보면 된다. |
Ø Multithreaded/Multicontextec 응용 프로그램에 대한 설계 및 디자인
|
① Mutithreading 과 Multicontexting 의 대한 정의 ② Mutithreaded/Multicontexted 응용 프로그램에 대한 장단점 ③ 클라이언트 측면에서의 Mutithreading/Multicontexting 의 작동법 ④ 서버 측면에서의 Mutithreading/Multicontexting 의 작동법 ⑤ Mutithreaded/Multicontexted 응용 프로그램 디자인시 고려사항 |
2. 고려사항
Ø Mutithreading 과 Multicontexting 의 대한 정의
|
① BEA Tuxedo 시스템은 하나의 프로세스가 다중의 타스크를 동시에 처리하는 것 지원 ② 이러한 프로그램 구현 테크닉을 Multithreading/Multicontexting 이라고 한다. |
Ø Multithreading 설명
|
|
참고설명) Multithreading 은 하나의 프로세스안에서 하나이상의 실행단위를 포함하는 개념이다.
Multithreaded 응용 프로그램에서는 같은 프로세스내에서 다중의 동시호출을 할 수 있다.
하나의 프로세스에서 오직 하나의 tpcall() 호출만을 할 수 있는 것은 아니다.
서버에서 Multithreading 은 Single Context 서버(하나의 서버)내에서 직접 구현한 쓰레드
프로그램을 제외하고 Multicontexting 기능을 필요로 한다.
Single Context 이면서 Multitheaded 응용 프로그램을 작성하고자 하는 유일한 방법은
직접 응용 프로그램내에서 쓰레드를 구현하는 것이다.
BEA Tuxedo 시스템은 C 로 작성된 Multithreaded 응용 프로그램을 지원하지만,
COBOL 은 지원하지 않는다.
위 그럼은 하나의 Multithreaded 된 클라이언트 프로그램이 동시에 3 개의 서버를 호출
하는지를 보여준다.
Multithreaded 응용 프로그램에서 다중 서비스 호출에 대한 쓰레드 분배기능이 같은
서버에서 가능한다.
즉, 이것은 해당 응용 프로그램을 위해서 부팅되야 하는 서버의 갯수를 줄이는 효과를
제공한다.
다음 그림은 어떻게 하나의 서버가 동시에 서로 다른 클라이언트에 대한 쓰레드를
분배하는지를 보여준다.
|
|
참고설명) 위의 정보는 XA 방식을 사용하지 않는 형태의 GROUPS 섹션 정보를 보여주고 있다.
Ø Multicontexting 설명
|
|
참고설명) Context 란 도메인과의 연결을 의미한다. Multicontexting 은 하나의 프로세스가 다음과
같은 조건중에 하나를 가지고 있는 것을 의미한다.
- 하나의 도메인내에서 하나이상의 연결을 유지
- 하나이상의 도메인에 연결을 유지
Multicontexting 은 클라이언트 및 서버 모두에 사용할 수 있으며, 서버에 사용될 경우에는
Multicontexting 은 Multithreading 의 사용이 반드시 지원되어야 한다.
BEA Tuxedo 시스템은 C 언어 또는 COBOL 언어로 작성된 Multicontexted 응용 프로그램을
지원한다. 물론, Mutithreaded 응용 프로그램은 C 언어에서만 지원된다.
위 그림은 Multicontexted 클라이언트 프로그램이 복수의 도메인내에서 어떻게 작동하는지
를 보여준다. 각 화살표는 하나의 서버에 서비스 호출을 나타낸다.
Ø Multithreaded/Multicontexted 응용 프로그램에서의 라이센스
|
하나의 Context 는 하나의 유저로 산정된다. 하나의 Context 내에서 다중 쓰레들를 구현하는 것은 추가 라이센스를 필요로 하지 않는다. 만약, 하나의 프로세스가 응용 프로그램 A 에 2 개의 Context 와 응용 프로그램 B 에 1 개의 Context 를 가지고 있다면, 총 3 유저의 라이센스가 된다. 즉, 하나의 프로세스가 하나의 동일한 Context 내에서 하나의 응용 프로그램에 접속하는 다중 쓰레드라면, 오로지 1 유저의 라이센스만이 산정된다. |
Ø Mutithreaded/Multicontexted 응용 프로그램에 대한 장단점
|
Multithreaded/Multicontexted 응용 프로그램 장점 ① 개선된 속도와 동시처리 특정 어플리케이션에서 Multithreading 과 Multicontexting 을 같이 사용함에 따라 속도와 동시처리 성능이 개선될 수 있다. 그러나, 다른 어플리케이션에서는 해당 기능을 같이 사용함에 따라 전혀 개선되지 않거나 오히려 속도가 저하되는 경우될 수 있다. 즉, 속도에 영향을 미치는 것은 여러분의 어플리케이션에 좌우된다. ② 리모트 호출(RPC) 와 대화형(Conversations) 프로그램 코딩의 단순화 어떤 어플리케이션에서는 같은 쓰레드안에서 RPC 와 Conversations 를 모두 관리하 는 것보다 서로 별개의 쓰레드에서 관리하도록 코딩하는 것이 더 쉽다. ③ 여러개의 응용 프로그램에 동시에 접근할 수 있는 기능 여러분의 BEA Tuxedo 클라이언트는 한번에 하나이상의 응용 프로그램에 접속할 수 있다. ④ 필요한 서버의 수를 감소시키는 기능 하나의 서버가 여러개의 서비스 요청를 쓰레드에 분배할 수 있기 때문에, 응용 프 로그램의 위해 필요한 서버의 수가 감소된다. 이 기능은 특히 대화형 서버에 유용하다, 왜냐하면, 대화형 서버는 해당 대화가 지속동안 오로지 하나의 클라이언트에 종속되기 때문이다. Multithreaded/Multicontexted 응용 프로그램 단점 ① 코딩의 어려움 Multithreaded 와 Multicontexted 응용 프로그램은 작성하기가 쉽지 않다. 오직 경험이 있는 개발자만이 이러한 유형의 어플리케이션 코딩을 담당해야 한다. ② 디버깅의 어려움 Single-contexted/Single-threaded 응용 프로그램보다 Multithreaded/Multicontexted 응용 프로그램에서 오류를 재현하기가 훨씬 더 어렵 다. 결과적으로 오류가 발생했을 때 오류의 원인을 찾아내는 데 훨씬 더 어렵다는 것이다. ③ 동시성 제어의 어려움 쓰레드간의 동시성 제어를 하는 것은 어려울뿐만 아니라, 응용 프로그램에 또 다른 새로운 문제을 야기할 수 있는 잠재성을 안고 있다. ④ 테스트의 어려움 Single-threaded 프로그램보다 Multithreaded 프로그램의 테스트가 더 어렵다. 왜냐하면, 문제점은 종종 time-related 이며 오류를 재현하기가 훨씬 더 어렵기 때문이다. ⑤ 기존 프로그램 코드에 적용이 어려움 기존 프로그램 코드가 Multithreading/Multicontexting 기능을 사용하고자 하면 기존 프로그램 코드이 재구성이 종종 필요하다. l 정적(Static) 변수를 제거해야 한다. l thread-safe 형태가 아닌 함수들을 대체해야 한다. l thread-safe 형태가 아닌 프로그램 코드를 대체해야 한다. 해당 기능을 완전히 적용시키기 위해서는 많은 테스트가 필요하기 때문에 Multithreaded/Multicontexted 응용 프로그램을 적용하는데는 필요한 작업이 수반 된다. |
Ø 클라이언트 측면에서의 Mutithreading/Multicontexting 의 작동법
|
Multithreaded/Multicontexted 응용 프로그램이 사용가능한 상태라면, 클라이언트의 Life Cycle 은 3 가지 단계로 나타낼 수 있다. ① Start-up 단계 ② Work 단계 ③ Completion 단계 |
Ø Start-up 단계에서는 다음과 같은 이벤트가 발생한다.
|
l 일부 클라이언트 쓰레드는 tpinit() 함수를 호출하여 하나 또는 그 이상의 BEA Tuxedo 응용 프로그램에 접속할 수 있다. l 다른 클라이언트 쓰레드는 tpsetctxt() 함수를 사용하여 Context 들을 공유한다. l 일부 클라이언트 쓰레드는 여러개의 Context 에 접속할 수 있다. l 일부 클라이언트 쓰레드는 기존에 존재하는 Context 에 스위칭할 수 있다. |
참고사항) BEA Tuxedo 시스템과는 별도로 동작하는 쓰레드가 있을 수 있지만, 여기서는 그런한
쓰레드 사용은 언급하지 않는다.
Ø 클라이언트 쓰레드가 여러개의 Context 에 접속할 수 있는 기능
BEA Tuxedo Muticontexted 응용 프로그램에서 클라이언트는 다음과 같은 조건이 충족된다면
하나이상의 응용 프로그램에 접속할 수 있다.
l 응용 프로그램에 대한 모든 접속이 BEA Tuxedo 시스템이 설치된 곳과 같아야 한다.
l 응용 프로그램에 대한 모든 접속이 동일한 유형의 클라이언트 프로그램이어야 한다. 즉, 클라이언트가 모두 Native 이던지 아니면 WS(WorkStation) 이어야 한다.
Multicontext 에 접속하기 위해서 클라이언트는 TPINFO 데이타 타입의 flags 변수에
TPMULTICONTEXTS 플래그를 설정하여 tpinit() 함수를 호출해야 한다.
이 플래그를 설정한 후에 tpinit() 함수를 호출하면, 새로운 접속이 생성되며, 해당 접속은
현재 쓰레드에 대한 접속이 된다.
새로운 접속을 하게 되는 BEA Tuxedo 도메인은 TUXCONFIG 또는 WSENVFILE/WSNADDR
환경변수에 설정된 값에 의해 결정된다.
Ø 클라이언트 쓰레드를 기존 존재하는 Context 에 스위칭하는 기능
대부분의 ATMI 함수들은 하나의 Context 기반하에 동작한다.
그러한 경우에 Target Context 는 현재 Context 이다. 비록, 클라이언트가 하나 이상의 Context 에 접속된 상태라 하더라도 일정 시점의 임의의 쓰레드에서는 오직 하나의 Context 가 현재 Context 가 된다.
하나의 응용 프로그램내에서 업무 속성이 변경됨에 따라 때때로, 임의의 Context 에서 다른 Context 로 쓰레드를 재할당하는 것이 이로울 때가 있다.
그러한 경우, 클라이언트 쓰레드는 tpgetctxt() 함수를 호출하여 그 함수가 돌려준 핸들을 다른 클라이언트 쓰레드에게 건네준다. 핸들을 건네 받은 클라이언트 쓰레드는 tpsetctxt() 함수를 사용하여 현재 Context 를 설정한다.
핸들을 건네 받은 쓰레드는 Context 기반하에 동작하는 ATMI 함수들을 사용하여 업무처리를 할 수 있다.
Ø Work 단계에서는 다음과 같은 업무처리를 수행한다.
|
l 쓰레드는 서비스 요청을 한다. l 쓰레드는 서비스 요청에 대한 응답을 얻는다. l 쓰레드는 대화형 서비스를 시작하던지 혹은 관여한다. l 쓰레드는 트랜잭션을 시작/커밋/롤백처리를 한다. |
Ø 서비스 요청
쓰레드는 tpcall() 함수 또는 tpacall() 함수를 사용하여 서비스 요청을 한다.
만약, tpcall() 함수를 사용했다면, 해당 쓰레드는 응답이 올 때까지 블락킹된다.
Ø 서비스 요청에 대한 응답
tpacall() 함수를 사용한 경우에는 반드시 해당 함수를 사용한 쓰레드가 아니더라도 상관없지만,
tpgetrply() 함수는 tpacall() 함수를 사용한 시점의 Context 와 같은 Context 에서 사용해야
한다. 즉, 동일한 Context 내에서 서비스 요청과 응답이 있어야 한다는 의미이다.
Ø 트랜잭션
하나의 쓰레드가 임의의 트랜잭션을 시작하면, 해당 쓰레드가 속한 Context 내의 모든 쓰레드는 해당 트랜잭션을 공유한다.
하나의 Context 에 속하는 여러 쓰레드들은 하나의 트랜잭션상에서 작업을 할 수 있지만,
오로지 한 쓰레드만이 해당 트랜잭션을 커밋 또는 롤백할 수 있다.
해당 트랜잭션을 커밋 또는 롤백하는 쓰레드는 해당 트랜잭션상에서 작업중인 임의의 쓰레드
가 될 수 있다. 즉, 반드시 트랜잭션을 시작한 쓰레드일 필요는 없다.
쓰레드 응용 프로그램은 트랜잭션에 대한 일반적인 규칙이 적용될 수 있도록 적절한
동기화 작업을 제공하여야 한다.
예를들면, 트랜잭션이 커밋되었을 때 남아있는 RPC(Remote Procedure Call) 이나 Conversation 이 있어서는 안된다.
또한, 트랜잭션이 커밋 또는 롤백된 이후로는 비정상적인 호출은 허용되지 않는다.
프로세스는 각 응용 프로그램의 Association 에 대하여 많아야 한 트랜잭션의 일부분만이
될 수 있다.
응용 프로그램의 한 쓰레드가 해당 응용 프로그램의 다른 쓰레드의 RPC(Remote Procedure Call) 또는 Converational Call 과 함께 동시에 tpcommit() 을 호출한다면, 턱시도 시스템은 마치 일련의 순서대로 해당 호출이 발행되도록 작동한다.
응용 프로그램 Context 는 중간에 tpsuspend() 를 사용하여 트랜잭션상의 작업을 중지할 수 있다.
그리고 Single-threaded 와 Single-Context 프로그램에 적용되는 동일한 제한조건하에서 다른 트랜잭션을 시작할 수 있다.
Ø Unsolicited Messages
Multithreaded 와 Multicontexted 응용 프로그램의 각 Context 에 대하여,
여러분은 Unsolicited 메세지를 제어하기 위한 3 가지 방법중에 한 가지를 선택할 수 있다.
|
Context 선택방식 |
설정방법 |
|
Unsolicited Messages 무시 |
TPU_IGN |
|
Dip-in notification 사용 |
TPU_DIP |
|
전용 thread notification 사용(C 응용 프로그램에서만 허용) |
TPU_THREAD |
다음과 같은 주의사항이 적용된다.
1) SIGNAL-based notification 은 multithreaded 또는 multicontexted 프로세스에서는 허용되지
않는다.
2) 만약, 여러분의 응용 프로그램이 multicontexting 은 지원하지만, multithreading 은 지원하지
않는 플랫폼에서 운영된다면, 여러분은 TPU_THREAD 설정방법을 사용할 수 없다.
결국, 여러분은 즉시로 notification 이벤트를 받을 수 없다.
만약, 즉시로 해당 notification 이벤트를 받는 것이 여러분의 응용 프로그램에서 중요하다면
여러분은 해당 플랫폼에서 multicontexted 방법을 사용하는 것에 대하여 주의깊게 생가해봐야
한다.
3) 전용 thread notification 은 C 로 작성된 응용프로그램이나 BEA Tuxedo 시스템에서 지원되는
multithreaded 플랫폼에서만 사용가능하다.
전용 thread notification 이 선택되어 진다면, 턱시도 시스템은 unsolicited 메세지를 받아서
unsolicited 메세지 핸들러에 분배하기 위해 별개의 독립된 쓰레드를 사용한다.
주어진 Context 에서는 어느 한 시점에서는 unsolicited 메세지 핸들러중에 오직 하나만이 실행될
수 있다.
tpinit() 이 BEA Tuxedo 시스템이 쓰레드를 지원하지 않는 플랫폼에서 TPU_THREAD notification
을 설정하여 호출한다면, tpinit() 은 -1 을 리턴하고 tperrno 에 TPEINVAL 을 설정한다.
또한, UBBCONFIG 파일에서 NOTIFY 옵션을 THREAD 로 설정했지만, 특정 노드에서 쓰레드가
지원되지 않는다면, 해당 노드는 자동적으로 DIPIN 방식으로 변환된다.
위 2 가지 방식의 주된 차이점은 관리자가 복잡한 구성환경에 있는 모든 노드에 대하여 기본
설정방법을 지정할 수 있다는 것이다.
여기서, 복잡한 환경이란 일부는 쓰레드를 지원하고 일부는 지원하지 않는 환경을 말한다.
하지만, 클라이언트가 명시적으로 해당 노드에서 허용되지 않는 설정방식을 지정하는 것을
허용하지 않는다.
tpsetunsol() 이 Context 에 아직 연결이 안된 쓰레드에서 호출된다면, tpinit() 을 통하여
새로 만들어지는 Context 에 대하여 default unsolicited 메세지 핸들러가 된다.
Context 는 해당 Context 가 활동상태라면 다시 tpsetunsol() 을 사용하여 해당 Context 에 대한
unsolicited 메세지 핸들러를 변경할 수 있다.
프로세스의 default unsolicited 메세지 핸들러는 Context 와 현재 연결이 안된 쓰레드에서
tpsetunsol() 을 사용하여 변경할 수 있다.
만약, 한 응용 프로그램에 대하여 여러개의 Association 을 가지고 있다면, 개별 Association 은
unsolicited 메세지를 특정 응용 프로그램 Association 에게 보낼 수 있도록 서로 다른 CLIENTID
를 할당받는다.
만약, 한 응용 프로그램에 대하여 여러개의 Association 을 가지고 있다면, broadcast 조건을
만족하는 응용 프로그램 Association 각각에 대하여 독립적으로 tpbroadcast() 의 메세지를
보낼 수 있다.
unsolicited 메세지를 검사하기 위해 dip-in 방식을 수행한다면, 응용 프로그램은 현재 응용
프로그램 Association 에게 보내진 메세지들에 대해서만 검사를 한다.
unsolicited 메세지 핸들러에 허용된 ATMI 함수에 추가로, unsolicited 메세지 핸들러 내부에서
tpgetctxt() 를 사용할 수 있다.
이 함수는 unsolicited 메세지 핸들러가 같은 Context 안에서 어떤 다른 ATMI 작업을 하기 위해
또 다른 쓰레드를 만들수 있도록 한다.
Ø Userlog 는 쓰레드와 관련된 정보를 유지한다.
각 응용 프로그램에 있는 개별 쓰레드에 대해서, 다음과 같은 식별정보를 userlog 에 기록한다.
|
process_ID.thread_ID.context_ID |
참고사항) 여기서 placeholders([ ]) 는 non-threaded 플랫폼과 Single-Contexted 응용 프로그램의
경우 thread_ID 와 context_ID 위치에 출력된다.
TM_MIB 는 T_ULOG 클라스의 TA_THREADID 와 TA_CONTEXTID 에 해당 기능을
제공한다.
Ø Completion 단계에서는 다음과 같은 업무처리를 수행한다.
클라이언트 프로세스가 exit 하려고 할 때, 현재 context 와 관련된 모든 쓰레드를 위하여
쓰레드는 tpterm() 을 사용하여 해당 응용 프로그램 Association 을 종료한다.
다른 ATMI 함수와 같이 tpterm() 은 현재 Context 상에서 작동하며, 또한, 현재 종료되는
context 에 종속된 모든 쓰레드에 영향을 미친다.
이들 쓰레드간에 공통으로 유지되는 Context 의 모든 부분을 종료시킨다.
잘 디자인된 응용 프로그램은 통상, tpterm() 함수를 호출하기 전에 해당 Context 에 있는
모든 작업이 완료되기를 기다린다.
여러분의 응용 프로그램이 tpterm() 함수를 호출하기 전에 모든 쓰레드가 동기화되었는지를
확인해야 한다.
Ø 서버 측면에서의 Mutithreading/Multicontexting 의 작동법
|
Multithreaded/Multicontexted 응용 프로그램이 사용가능한 상태라면, 서버의 Life Cycle 은 3 가지 단계로 나타낼 수 있다. ④ Start-up 단계 ⑤ Work 단계 ⑥ Completion 단계 |
Ø Start-up 단계
start-up 단계에서 일어나는 일은 턱시도 구성화일의 MINDISPATCHTHREADS 와
MAXDISPATCHTREADES 의 값에 의존한다.
|
MINDISPATCHTHREADS |
MAXDISPATCHTHREADS |
턱시도 처리과정 |
|
0 |
> 1 |
1. 하나의 thread dispatcher 생성 2. dispatcher 은 tpsvrinit() 호출 |
|
> 0 |
> 1 |
1. 하나의 thread dispatcher 생성 2. dispatcher 은 tpsvrinit() 호출 3. 서비스 요청을 제어하기 위한 추가 쓰레드 생성 및 생성된 쓰레드에 대한 추가 context 생성 4. 생성된 쓰레드는 tpsvrthrinit() 호출 |
Ø Work 단계
l 하나의 서버에 대한 다수의 클라이언트 요청은 다중 Context 상에서 동시에 제어된다. 시스템은 각 요청에 대하여 별도의 쓰레드를 할당한다.
l 필요하다면, 추가로 쓰레드가 MAXDISPATCHTHREADS 에 설정된 수만큼 생성된다.
l 턱시도 시스템은 서버 쓰레드에 대한 통계정보를 유지한다.
Server-dispatched Threads Are Used
서비스의 클라이언트 요청에 대한 응답시, 서버 dispatcher 는 하나의 서버안에서 동시에 여러
클라이언트 요청을 처리하기 위해 현재 최대로 만들수 있는 쓰레드수까지 생성할 수 있다.
서버는 tpinit() 함수를 사용하여 클라이언트가 될 수 없다.
개별로 dispatched 된 쓰레드는 각각의 context 와 연관되어져 있다. 이 기능은 conversational
서버와 RPC(Remote Procedure Call) 서버에서 유용하다. 특히, Conversational 서버에서 유용하다.
이 기능은 UBBCONFIG 파일의 SERVERS 섹션과 TM_MIB 에 있는 다음과 같은 파라미터에 의해
제어된다.
|
UBBCONFIG 파라미터 |
MIB 파라미터 |
Default |
|
MINDISPATCHTHREADS |
TA_MINDISPATCHTHREADS |
0 |
|
MAXDISPATCHTHREADS |
TA_MAXDISPATCHTHREADS |
1 |
|
THREADSTACKSIZE |
TA_THREADSTACKSIZE |
0(OS 의 기본설정치를 따름) |
l 각 dispatched 된 쓰레드는 THREADSTACKSIZE 또는 TA_THREADSTACKSIZE 에 의해 지정된 크기의 스택 사이즈가 만들어진다. 만약, 이 파라미터 값이 설정되어 있지 않거나 해당 값이 0 이라면 OS(운영체제)의 default 값이 사용된다.
l MINDISPATCHTHREADS 또는 TA_MINDISPATCHTHREADS 는 MAXDISPATCHTHREADS 또는 TA_MAXDISPATCHTHREADS 의 값과 같거나 작아야 한다.
l MAXDISPATCHTHREADS 또는 TA_MAXDISPATCHTHREADS 가 1 이라면, dispatcher 쓰레드와 서비스 쓰레드는 같다.
l MAXDISPATCHTHREADS 또는 TA_MAXDISPATCHTHREADS 가 1 보다 크다면, 다른 쓰레드를 dispatching 하기 위해 사용되는 임의의 쓰레드는 dispatched 되는 쓰레드의 Limit 에 계산되지 않는다.
l 초기에, 턱시도 시스템은 MINDISPATCHTHREADS 또는 TA_MINDISPATCHTHREADS 만큼의 쓰레드를 생성한다.
l 턱시도 시스템은 MAXDISPATHTHREADS 또는 TA_MAXDISPATCHTHREADS 를 초과하여 쓰레드를 생성할 수 없다.
Application-created Threads Are Used
여러분의 OS(운영체제)에서 제공하는 함수를 사용하여 해당 서버안에서 쓰레드를 생성할 수 있다.
해당 서버안에서 생성된 쓰레드는
l BEA Tuxedo 시스템과는 별개로 동작한다.
l 현재 dispatch 쓰레드와 같은 Context 에서 동작한다.
l dispatch context 를 위한 작업을 수행한다.
응용 프로그램안에서 쓰레드를 만든다면 일부 제약사항이 여러분이 행할 수 있는 작업을
제한한다.
l 서버는 tpinit() 함수를 호출하여 클라이언트가 될 수 없다.
l 초기에, 응용 프로그램안에서 만든 쓰레드는 어떠한 dispatch context 와도 연관되어 있지 않다. 하지만, tpsetctxt() 함수를 사용하여 자신을 dispatched context 와 연관지을 수 있다. (이전에 dispatched 쓰레드안에서 tpgetctxt() 함수의 리턴된 값을 인자로 설정)
l 응용 프로그램안에서 만든 쓰레드는 tpreturn() 또는 tpforward() 함수를 사용할 수 없다. 해당 쓰레드가 작업을 끝마쳤을 때, 원래 dispatched 쓰레드가 tpreturn() 함수를 호출하기 전에 TPNULLCONTEXT 플래그를 tpsetctxt() 함수에 설정하여 호출해야 한다.
BBL Verifies Sanity of System Processes
BBL 은 주기적으로 서버들을 검사한다. 만약, 한 서버가 특정 서비스 요청을 오랫동안 실행된다면, 해당 서버를 Kill 시킨다.(만약, 지정되었다면, BBL 은 해당 서버를 재기동한다.) 만약, BBL 이 multicontexted 서버를 kill 하게 되면, 현재 수행중인 다른 서비스 호출 또한 종료된다.
BBL 은 또한, 메세지를 받기 위해 자신의 지정된 시간보다 오랫동안 기다리는 프로세스 또는 쓰레드에게 메세지를 보낸다. 그러면 블록킹 메세지 수신 Call 은 타임 아웃을 나타내는 오류를 리턴한다.
Server Keeps Statistics on Server Threads
각 서버에 대해서, BEA Tuxedo 시스템은 다음과 같은 통계정보를 유지한다.
l 허용된 서버 dispatched 쓰레드의 최대 수
l 현재 사용중인 서버 dispatched 쓰레드의 수(TA_CURDISPATCHTHREADS)
l 해당 서버가 부팅된 이후로 최대로 dispatched 쓰레드의 수(TA_HWDISPATCHTHREADS)
l 과거에서 부터 기동된 서버 dispatched 쓰레드의 수(TA_NUMDISPATCHTHREADS)
Userlog Maintains Thread-specific Information
각 응용 프로그램에 있는 개별 쓰레드에 대해서, 다음과 같은 식별정보를 userlog 에 기록한다.
|
process_ID.thread_ID.context_ID |
참고사항) 여기서 placeholders([ ]) 는 non-threaded 플랫폼과 Single-Contexted 응용 프로그램의
경우 thread_ID 와 context_ID 위치에 출력된다.
TM_MIB 는 T_ULOG 클라스의 TA_THREADID 와 TA_CONTEXTID 에 해당 기능을
제공한다.
Ø Completion 단계
응용 프로그램이 셧다운되어질 때, tpsvrthrdone() 과 tpsvrdone() 함수가 리소스 매니저을 Close 한다든지 하는 필요한 종료처리 과정을 수행하기 위해 호출되어 진다.
Multithreaded 와 Multicontexted 응용 프로그램의 설계시 고려사항
해당 응용 프로그램을 만들기 위해서는 다음과 같은 몇가지의 기본적인 질문에 답을 해야 한다.
l 여러분의 개발 및 실행환경
l 응용 프로그램의 설계시 필수조건
l 사용할 쓰레드 모델의 타입
l 워크스테이션 클라이언트를 위한 서로간의 제약사항
Environment Requirements
multithreaed 또는 Multicontexted 응용 프로그램 개발을 하고자 하는 시점에서는 개발 및 운영시의 환경에 대하여 다음과 같은 사항을 조사해야 한다.
l Concurrency 와 Synchronization 을 관리하는 multithreaded 와 Multicontexted 응용 프로그램을 작성하고 디버깅할 수 능력을 가진 프로그램 개발팀을 가지고 있는가 ?
l 응용 프로그램을 작성하고자 하는 플랫폼에 BEA Tuxedo 시스템의 Multithreading 기능이 지원되는가 ?
l 개발된 서버에서 사용되는 RM(Resource Manager) 가 multithreading 을 지원하는가 ? 만약, 그렇다면 다음과 같은 Issue 을 고려해야 한다.
ü 해당 서버에서 multithreaded 로 운영하기 위해 RM 이 필요로 하는 파라미터 설정이 필요한가 ? 예를들면, multithreaded 응용 프로그램과 ORACLE 데이타베이스를 같이 사용한다면 ORACLE 에 넘겨주는 OPENINFO 정보의 일부분으로서 “THREADS=true” 라는 파라미터를 설정해야 한다. 그렇게 함으로 인해서 개별 쓰레드가 서로 독립된 ORACLE Association 으로 동작하도록 한다.
ü 사용하는 RM(Resource Manager) 가 mixed-mode 의 작업을 허용하는가 ? mix-mode 작업이란 하나의 프로세스안에 있는 여러개의 쓰레드가 RM 과 하나의 Association 과 맵핑되고 동시에 같은 프로세스안에서 또 다른 일부 쓰레드가 다른 RM Association 과 맵핑되는 것을 말한다. 예를들면, 하나의 프로세스안에 쓰레드 A 와 B 가 RM Association X 에 맵핑되고, 쓰레드 C 는 RM Association Y 에 맵핑되는 것을 말한다. 모든 RM 이 mixed-mode 을 지원하지는 않는다. 일부는 주어진 프로세스내의 모든 쓰레드가 같은 RM Association 을 필요한다. 만약, 응용 프로그램안에서 만든 쓰레드안에서 트랜잭션을 위해 RM 을 접근하는 응용 프로그램을 설계한다면, 여러분의 RM(Resource Manager) 가 mixed-mode 지원을 하는지를 확인해야 한다.
Design Requirements
Multithreaded 와 multicontexted 응용 프로그램을 설계할 때, 여러분은 다음과 같은 설계사항을 고려해야 한다.
l 여러분의 응용 프로그램에서 수행되는 업무가 multithreading 과 multicontexting 에 적합한가 ?
l 하나이상의 응용 프로그램에 접속하기를 원하는가 ? 개별 응용 프로그램에 얼마나 많은 접속을 하기를 원하는가 ?
l 여러분의 응용 프로그램에 어떠한 Synchronization 사항이 필요한가 ?
l 여러분의 Initial 프로그램을 실환경으로 적용한 후에, 여러분의 응용 프로그램을 다른 플랫폼에 포팅을 할 필요성이 있는가 ?
Is the Task of Your Application Suitable for Multithreading and/or Multicontexting
다음 도표는 여러분의 응용 프로그램이 multithreaded 와 multicontexted 로 작성되었을 때, 어느정도의 성능 향상이 있는지를 결정하는데 도움이 되는 질문 리스트를 제공한다.
해당 리스트는 반드시 모든 경우에 적합한 것은 아니며, 여러분의 개별적인 필요사항이 고려할 다른 사항들을 결정짓는다.
추가로, 더 필요한 질문사항들에 대해서는 multithreaded 와 multicontexted 프로그래밍 관련 서적을 살펴보는 것도 권고안이다.
|
질문사항 |
YES 시 권고하는 사용방법 |
|
도메인 기능을 사용하지 않고 하나이상의 응용 프로그램에 접속할 필요성 ? |
Multicontexting |
|
클라이언트가 응용 프로그램안에서 multiplexer 의 역할을 수행하는가 ? |
Multicontexting |
|
클라이언트가 multicontexting 을 사용하는가 ? |
Multithreading context 당 하나의 쓰레드 (프로그램 코드의 단순화) |
|
클라이언트가 쓰레드 Synchronization 의 비용과 복잡성보다는 Performance Gains 가 더 요구되는 환경에서 오랜 시간동안 실행되는 2 개 이상의 Task 가 수행되는가 ? |
Multithreading |
|
하나의 서버가 여러개의 요청을 동시에 처리하기를 원하는가 ? |
multithreading MAXDISPATHTHREADS 에 1 보다 큰 값을 설정 이 값은 해당 서버에 대해서 여러개의 클라이언트들이 자신의 쓰레드를 갖도록 한다. |
|
클라이언트나 서버가 다중 쓰레드를 갖는 다면, 각 쓰레드가 작업를 수행한 후에 쓰레드간에 Synchronize 가 필요한가 ? |
Not using multithreading |
How Many Applications and Connections Do You Want
여러분이 얼마나 많은 응용 프로그램에 접속해야 하는가와 어느 정도의 Connection 이 필요한가를 결정해야 한다.
l 하나이상의 응용 프로그램에 대한 Connection 을 필요한 경우, 다음과 같은 방법중에 하나를 사용하도록 권고한다.
ü A Single-threaded, multicontexted application
ü A multithreaded, multicontexted application
l 하나의 응용 프로그램에 하나 이상의 connection 을 필요한 경우, multithreaded, multicontexted 응용 프로그램을 사용하는 것을 권고한다.
l 하나의 응용 프로그램에 단지, 하나의 connection 이 필요한 경우, 다음과 같은 방법중에 하나를 사용하도록 권고한다.
ü Multithreaded, single-contexted clients
ü Single-threaded, single-contexted clients
위 2 가지의 경우, multithreaded, multicontexted 서버를 사용하는 것도 가능한다.
What Synchronization Issues Need to Be Addressed
이것은 설계(Design) 단계중에 중요하다. 그러나, 이 부분은 해당 문서의 범위를 벗어난다. multithreaded and/or multicontexted 프로그래밍에 대한 관련 서적을 참고하기를 바란다.
Will You Need to Port Your Application
추후, 여러분의 응용 프로그램을 다른 시스템에 Porting 할 필요성이 있다면, 서로 다른 OS(운영체제)는 서로 다른 함수들을 가지고 있다는 것을 명심해야 한다. 여러분이 하나의 플랫폼에서 처음 프로그램을 완성한 후에 해당 프로그램을 Porting 하고자 한다면, 해당 프로그램 코드를 Porting 할 시스템에 있는 함수들로 수정하는데 필요한 시간을 고려해야 한다.
Which Threads Model Is Best for You
multithreaded 프로그램에서는 다음과 쓰레드 모델이 사용되어질 수 있다.
l Boss/Worker model
l Siblings model
l Workflow model
해당 문서에서는 쓰레드 모델에 대해서는 설명하지 않는다. 여러분의 응용 프로그램을 위한 프로그래밍 모델을 선정할 때, 여러분이 직접 필요한 쓰레드 모델을 찾아보고 설계(Design)시 필요사항을 주의깊게 고려해야 하는 것이 권고안이다.
Interoperability Restrictions for Workstation Clients
턱시도/WS 버전이 7.1 이고 턱시도/T 버전이 7.1 이전 버전간에 통신을 할 경우에는 다음과 같은 경우에만 가능한다.
l 클라이언트가 multithreaded 도 아니고 multicontexted 도 아닌다.
l 클라이언트가 multicontexted 이다
l 클라이언트가 multithreaded 이고 각 쓰레드는 서로 다른 context 에 있다.
Single context 에서 multiple threads 로 된 BEA Tuxedo 배포판 7.1 Workstation client 는 BEA Tuxedo 시스템 7.1 이전 버전과는 서로 통신할 수 없다.
3. 구현방법
Implementing a Multithreaded/Multicontexted Application
l Multithreaded/Multicontexted 응용 프로그램 작성에 관한 예비 가이드 라인
l 클라이언트에서 Multicontexting 프로그램 작성법
l 서버에서 Multicontexting 과 Multithreading 프로그램 작성법
l Multithreaded 클라이언트 작성
l Multithreaded 서버 작성
l Multithreaded/Multicontexted 응용 프로그램 컴파일 방법
Preliminary Guidelines for Programming a Multithreaded/Multicontexted Application
코딩하기 전에, 다음과 같은 사항을 확인해야 한다.
l Multithreaded 응용 프로그램의 전제조건
l 일반적인 Multithreaded 프로그래밍의 고려사항
l Concurrency 고려사항
Prerequisites for a Multithreaded Application
개발 프로젝트를 진행하기 앞서 여러분의 환경이 다음과 같은 전제조건을 만족하는지를 확인해야 한다.
l OS(운영체제) 가 BEA Tuxedo 시스템에 지원되는 쓰레드에 대한 패키지를 제공해야 한다.
ü BEA Tuxedo 시스템은 쓰레드를 만드는 툴(Tool) 을 제공하지 않지만, 서로 다는 OS(운영체제) 에 의해 제공되는 여러가지의 쓰레드 패키지를 지원한다.
ü 쓰레드를 만들고 동기화하기 위해서, 여러분의 OS(운영체제) 에 Native 한 함수들을 사용해야 한다. 필요하다면, 여러분의 OS(운영체제) 에 의해 제공되는 쓰레드 패키지를 알아보기 위해서는 BEA Tuxedo 시스템 설치 부분에서 Platform Data Sheets 를 참조한다.
l 만약, multithreaded 서버을 사용한다면, 해당 서버에 의해 사용되는 RM(Resource Manager) 가 쓰레드를 지원해야 한다.
General Multithreaded Pogramming Considerations
경험이 많은 프로그래머들만이 multithreaded 프로그램을 작성해야 한다.
특히, 다음과 같은 Task 에 대해서 기본적인 설계(Design) 사항에 대하여 친숙해져 있어야 한다.
l 다중 쓰레드간에 Concurrency 제어에 대한 필요성
l 정적변수(Static Variables) 사용 배제에 대한 필요성
l Multithreaded 프로그램에서의 Signal 사용에 의해 파생되는 잠재적인 문제점
위 사항들은 논의할 사항들중에 일부분이며, 여기에 열거하기에는 너무나 많기 때문이다.
해당 문서에서는 Multithreaded 프로그램을 개발하는 프로그래머가 이미 위의 사항들에 친숙해져 있다고 간주한다.
multithreaded 프로그래밍에 관하여 출판된 서적이 많으므로 해당 자료에서 위의 열거한 사항외에 다른 사항들을 참고해야 한다.
Concurrency Considerations
Multithreading 은 같은 Conversation 에서 각각의 응용 프로그램 쓰레드가 동시에 작업을 할 수 있도록 한다.
우리는 이러한 접근방법을 권고하지는 않지만, BEA Tuxedo 시스템은 그것을 금지하지는 않는다.
서로 다른 쓰레드가 같은 Conversation 에서 동시에 작업을 한다면, 턱시도 시스템은 동시 작업이 마치 일정한 순서가 없이 수행되었다고 간주한다.
다중 쓰레드 프로그래밍을 할 때, 여러분은 mutexes 또는 다른 동시성 제어 함수들을 사용하여 쓰레드간에 동시성(Concurrency)을 관리해야 한다.
다음은 동시성 제어(Concurrency Control) 를 위한 필요한 3 가지 예제를 기술한다.
l multithreaded 쓰레드가 같은 Context 에서 운영된다면, 프로그래머는 실행되는 함수들이 필요한 순서대로 실행되는지를 확인해야 한다. 예를들면, 모든 RPC(Remote Procedure Call) 와 Conversations 는 tpcommit() 함수가 호출되기 전에 완료되어야 한다. 만약, tpcommit() 함수가 모든 RPC(Remote Procedure Call) 과 Conversation 을 수행하는 다른 쓰레드와 다른 쓰레드에서 호출된다면, 아마도, 동시성 제어(Concurrenty Control) 이 응용 프로그램에서 필요하게 된다.
l 유사하게, 한 쓰레드에서 tpacall() 함수를 호출하고 다른 쓰레드에서 tpgetrply() 함수를 호출하는 것을 허용하지만, 응용 프로그램은 tpgetrply() 함수 호출전에 tpacall() 함수가 호출되어져야 한다. 또한 tpgetrply() 함수 호출전에 tpacall() 함수가 호출되지 않았을 때의 상황을 관리해야 한다.
l 다중 쓰레드는 같은 Conversation 에서 동작할 수 있지만, 응용 프로그램 프로그래머는 서로 다른 쓰레드가 거의 동시에 tpsend() 함수를 호출한다면, 턱시도 시스템은 마치 이러한 tpsend() 호출이 일정한 순서가 없이 수행된 것처럼 작동한다는 것을 알고 있어야 한다.
대부분의 응용 프로그램에 있어서, 최선의 전략은 하나의 Conversation 에 일어나는 모든 작업은 하나의 쓰레드에 코딩하는 것이다. 두번째로 최선의 전략은 동시성 제어(Concurrency Control) 를 사용하여 이러한 작업을 순서화하는 것이다.
Writing Code to Enable Multicontexting in a Client
클라이언트에서 multicontexting 을 하려면, 여러분은 다음과 같은 코드를 작성해야 한다.
l 초기화 시점에 multicontexting 을 Set up
l Security 구현
l 또한 multithreading 이 사용된다면, 쓰레드를 동기화
l Context 를 스위칭
l 각 Context 에 대한 unsolicited 메세지를 핸들링
만약, 여러분의 응용 프로그램이 트랜잭션을 사용한다면, 여러분은 트랜잭션에 대한 multicontexting 에 대한 결과를 알아두어야 한다.
더 상세한 정보는 Coding Rules for Transactions in a Multithreaded/Multicontexted Application 를 참조한다.
Note) 해당 문서에서 제공되는 명령어와 샘플 코드는 BEA Tuxedo 시스템에서 제공된 C 라이브러리 함수를 참조한다. 같은 COBOL 라이브러리 함수들 또한 사용가능하다. 상세한 설명은 BEA Tuxedo COBOL Function Reference 를 참조한다.
Context Attributes
코드를 작성할 때, Context 에 대한 다음과 같은 사항을 고려해야 한다.
l 원래 dispatched 쓰레드가 exit 하기전에 context 의 변경이 없이 application-created 서버 쓰레드가 종료된다면, tpreturn() 또는 tpforward() 는 실패한다. 쓰레드 종료처리는 자동으로 해당 Context 를 TPNULLCONTEXT 로 변경하기 위해 tpsetctxt() 함수를 호출하지 않는다.
l 프로세스에서 모든 Context 에 대하여, 같은 버퍼타입 스위치가 사용되어져야 한다.
l 데이타 구조체의 다른 타입과 더불어, multithreaded 응용 프로그램은 BEA Tuxedo 버퍼를 적절하게 사용해야 한다. 즉, 버퍼들은 다음과 같은 조건중 하나라도 만족하면 2 Calls 에서 동시에 사용되어서는 안된다.
ü Both Calls 는 해당 버퍼을 사용한다.
ü Both Calls 는 해당 버퍼를 Free 한다.
ü One Call 은 해당 버퍼를 사용하고 다른 one Call 은 해당 버퍼를 Free 한다.
l 만약, 여러분이 여러 응용 프로그램에 조인하거나 하나의 응용 프로그램에 다중 Connection 을 하고자 하여 tpinit() 함수를 한번 이상 호출한다면, 각 tpinit() 함수에 대하여, 여러분은 어떠한 Security 메커니즘이 Established 되어야 하는지를 조정해야 한다.
Setting Up Multicontexting at Initialization
클라이언트가 응용 프로그램에 조인할 준비가 되었을 때, 다음과 같은 코드에서 보여진 것처럼 TPMULTICONTEXTS 플래그와 함께 tpinit() 함수를 호출해야 한다.
|
#include <stdio.h> #include <atmi.h>
TPINIT *tpinitbuf;
main() { tpinitbuf = tpalloc(“TPINIT”, NULL, TPINITNEED(0)); tpinitbuf->flags = TPMULTICONTEXTS; ..... if(tpinit(tpinitbuf) == -1){ ERROR_PROCESSING_CODE } ..... } |
새로운 Application Association 이 만들어 지고 TUXCONFIG 파일에 지정된 혹은 WSENVFILE/WSNADDR 환경변수에 지정된 BEA Tuxedo 도메인에 할당된다.
Note) 프로세스상에서, tpinit() 함수호출시 모두가 TPMULTICONTEXTS 플래그를 포함하든지 아니면 해당 플래그를 전혀 포함하지 않든지 해야 한다. 위 Rule 에서 제외되는 한가지 예외는 클라이언트 Application Association 모두가 성공적으로 tpterm() 함수에 의해 종료되고, 처리과정이 tpinit() 을 다음에 호출하는 시점에 TPMULTICONTEXTS 플래그의 사용이 옵션이 되는 상태로 복귀된 경우이다.
Implementing Security for a Multicontexted Client
같은 프로세스안에서 각각의 Application Association 은 독립된 Security Validation 을 필요로 한다.
해당 Validation 의 본성은 여러분의 응용 프로그램에서 사용되는 Security 메커니즘의 타입에 의존한다.
예를들면, BEA Tuxedo 응용 프로그램에서, 여러분은 System-level 패스워드나 Application 패스워드를 사용할 수 있다.
Multicontexted 응용 프로그램의 프로그래머로서, 여러분은 여러분의 응용 프로그램에서 사용되는 Security 타입을 식별하고 프로세스안에서 개별 Application Association 에 대하여 그것을 구현하는 것을 책임져야 한다.
Synchronizing Threads Before a Client Termination
응용 프로그램으로 부터 클라이언트를 Disconnect 할 준비가 되었을 때, tpterm() 함수를 호출한다.
그러나, multicontexted Application 에서 tpterm() 함수는 현재 context 를 Destory 한다는 것을 명심해야 한다.
해당 context 에서 운영되는 모든 쓰레드가 영향을 받는다. 응용 프로그래머로서, 여러분은 tpterm() 함수가 의도되지 않게 호출되는 것이 없도록 다중 쓰레드의 사용을 주의깊게 조정해야 한다.
해당 Context 에서 작업중인 다른 쓰레드가 있는 경우, 해당 Context 에서 tpterm() 함수를 호출하는 것을 피하는 것은 중요하다.
만약, 그러한 상황이 발생하면, BEA Tuxedo 시스템은 해당 Context 에서 작업중이던 쓰레드의 Context 의 상태를 Invalid 상태로 놓는다.
Invalid context 상태에서는, 대부분의 ATMI 함수들은 사용할 수 없다. 쓰레드는 tpsetctxt() 함수 또는 tpterm() 함수을 사용하여 해당 상태에서 벗어날 수 있다.
잘 설계된 대부분의 응용 프로그램은 Invalid context 상태에서 결고 작업을 수행하지 않는다.
Note) BEA Tuxedo 시스템은 COBOL 응용 프로그램에서 multithreading 을 지원하지 않는다.
Switching Contexts
다음은 2 개의 Context 를 사용하여 클라이언트로부터 서비스를 호출하는 코딩 절차의 요약이다.
1. TUXCONFIG 환경변수를 firstapp 에서 필요로 하는 값으로 설정한다.
2. TPMULTICONTEXTS 플래그와 함께 tpinit() 함수를 사용하여 First Application 과 조인한다.
3. tpgetctxt() 함수를 사용하여 현재 Context 에 대한 핸들을 얻는다.
4. tuxputenv() 함수를 사용하여 secondapp Context 에서 필요로 하는 TUXCONFIG 환경변수의 값을 변경한다.
5. TPMULTICONTEXTS 플래그와 함께 tpinit() 함수를 사용하여 Second Application 과 조인한다.
6. tpgetctxt() 함수를 사용하여 현재 Context 에 대한 핸들을 얻는다.
7. First Context 에서 작업하기 위해, tpsetctxt() 함수를 사용하여 Context 를 스위칭한다.
8. Firstapp 서비스를 호출한다.
9. 클라이언트를 tpsetctxt() 함수를 사용하여 secondapp context 로 스위칭하고 secondapp 서비스를 호출한다.
10. 클라이언트를 tpsetctxt() 함수를 사용하여 firstapp context 로 스위칭하고 firstapp 서비스를 호출한다.
11. tpterm() 함수를 사용하여 firstapp context 를 종료한다.
12. tpsetctxt() 함수를 사용하여 현재 클라이언트 context 를 secondapp context 로 스위칭하고 secondapp 서비스를 호출한다.
13. tpterm() 함수를 사용하여 secondapp context 를 종료한다.
다음 샘플 코드는 이러한 절차에 대한 예제 프로그램이다.
Note) 샘플 코드를 단순화하기 위해, 오류 검사 코드는 포함되어 있지 않다.
|
#include <stdio.h> #include “atmi.h” #if definded(__STDC__) || definded(__cplusplus) main(int argc, char *argv[]) #else main(argc, argv) int argc; char *argv[]; #endif { TPINIT *tpinitbuf; TPCONTEXT_T firstapp_contextID, secondapp_contextID;
/* 환경변수 TUXCONFIG=/home/firstapp/TUXCONFIG 이 설정되었다고 가정 */ /* Multicontext 모드로 턱시도 시스템에 접속 */ tpinitbuf = tpalloc(“TPINIT”, NULL, TPINITNEED(0)); tpinitbuf->flags = TPMULTICONTEXTS;
if(tpinit((TPINIT *)tpinitbuf) == -1){ (void) fprintf(stderr, “Tpinit failed\n”); exit(1); }
/* 현재 Context 에 대한 핸들을 획득 */ tpgetctxt(&firstapp_contextID, 0);
/* tuxputenv 함수를 사용하여 TUXCONFIG 의 값을 변경하여 tpinit 함수 실행 */ tuxputenv(“TUXCONFIG=/home/second_app/TUXCONFIG”);
/* Second App 에 접속 */ if(tpinit((TPINIT *)tpinitbuf) == -1){ (void) fprintf(stderr, “Tpinit failed\n”); exit(1); }
/* Secondapp 에 대한 Context 핸들을 획득 */ tpgetctxt(&secondapp_contextID, 0);
/* 현재 Context 를 firstapp Context 로 변경 */ tpsetctxt(firstapp_contextID, 0);
/* firstapp 에서 제공되는 서비스 호출(생략) */ /* 현재 Context 를 Secondapp Context 로 변경 */ tpsetctxt(secondapp_contextID, 0);
/* secondapp 에서 제공되는 서비스 호출(생략) */
/* 현재 Context 를 firstapp Context 로 변경 */ tpsetctxt(firstapp_contextID, 0);
/* firstapp 에서 제공되는 서비스 호출(생략) */
/* firstapp 에 대한 context 종료 */ tpterm();
/* 현재 Context 를 secondapp Context 로 변경 */ tpsetctxt(secondapp_contextID, 0);
/* secondapp 에서 제공되는 서비스 호출(생략) */
/* secondapp 에 대한 context 종료 */ tpterm();
/* 프로그램 종료 */ return(0); } |
Handling Unsolicited Messages
각각의 Context 에 대하여 unsolicited 메세지를 핸들링하기 원한다면, 여러분은 unsolicited 메세지 핸들러를 설정해야 하거나 또는 이미 설정했다면 그것을 기본이 되는 프로세스 핸들러로 사용해야 한다.
tpsetunsol() 함수가 현재 Context 와 Associated 되지 않은 상태에서 호출된다면, 새롭게 만들어지는 tpinit() 함수의 context 에 대한 기본 unsolicited 메세지 핸들러가 된다.
특정 Context 는 해당 Context 가 Active 상태일 때, 다시 tpsetunsol() 함수를 사용하여 해당 Context 에 대한 unsolicited 메세지 핸들러를 변경할 수 있다.
해당 기본 프로세스 메세지 핸들러는 현재 Context 와 Associated 되지 않은 쓰레드에서 다시 tpsetunsol() 함수를 사용하여 변경되어질 수 있다.
Single-threaded 또는 Single-contexted application 에 설정하는 방법과 동일한 방법으로 해당 핸들러를 설정한다. 자세한 설명은 tpsetunsol() 함수를 참조한다.
여러분은 현재 여러분이 작업하고 있는 Context 식별자를 알기 위해 unsolicited 메세지 핸들러에서 tpgetctxt() 함수를 사용할 수 있다.
Coding Rules for Transactions in a Multithreaded/Multicontexted Application
여러분이