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
여러분이 응용 프로그램을 작성하면서 트랜잭션을 사용한다면 다음과 같은 사항을 고려해야 한다.
l 한 Context 안에서는 단지, 하나의 트랜잭션만을 가질 수 있다.
l 개별 Context 에 대하여 서로 다른 트랜잭션을 가질 수 있다.
l 주어진 시점에 주어진 Context 에 있는 모든 쓰레드는 해당 Context 에 대하여 같은 트랜잭션 상태를 공유한다.
l 여러분이 tpcommit() 함수를 호출하기 전에 모든 Conversation 과 RPC(Remote Procedure Call) 이 완료될 수 있도록 쓰레드들을 동기화해야 한다.
l 특정 트랜잭션에 대해서 단지, 하나의 쓰레드로부터만이 tpcommit() 함수를 호출해야 한다.
Writing Code to Enable Multicontexting and Multithreading in a Server
l Multicontexted 서버를 위한 코딩 규칙
l 서버와 서버 쓰레드의 초기화 및 종료
l 쓰레드를 만들기 위한 서버 프로그래밍
l Multicontexted 서버에 있는 application 쓰레드를 만들기 위한 샘플 코드
Note) 해당 문서에서 제공되는 명령어와 샘플 코드는 BEA Tuxedo 시스템에서 제공되는 C 라이브러리 함수들을 참조한다.(자세한 설명은 BEA Tuxedo C Function Reference 를 참조)
같은 기능의 COBOL 루틴은 multithreading(which is required to create a multicontexted server) 은 COBOL 응용 프로그램에서는 지원되지 않기 때문에 사용할 수 없다.
Context Attributes
여러분의 코드를 작성할 때, Context 에 대한 다음과 같은 고려사항을 생각해봐야 한다.
l application-created 서버 쓰레드가 원래의 dispatched 쓰레드가 종료하기전에 Context 의 변경없이 종료한다면, tpreturn() 또는 tpforward() 함수는 실패한다. 쓰레드 종료처리는 해당 Context 를 TPNULLCONTEXT(-2) 를 변경하는 tpsetctxt() 함수를 자동으로 호출하지 않는다.
l 프로세스내 모든 Context 에 대하여, 같은 버퍼타입 스위치가 사용되어야 한다.
l multithreaded application 은 BEA Tuxedo 버퍼를 적절히 사용해야 한다. 즉, 다음과 같은 조건중에 하나라도 만족한다면, 동시에 2 Calls 에서 사용되어서는 안된다.
ü Both Calls 가 같은 버퍼를 사용한다.
ü Both Calls 가 같은 버퍼를 해제한다.
ü One Call 은 해당 버퍼를 사용하고 one Call 이 해당 버퍼를 해제한다.
Coding Rules for a Multicontexted Server
multicontexted 서버를 코딩하기 위해서는 다음과 규칙을 명심해야 한다.
l 해당 서버에 있는 BEA Tuxedo dispatcher 는 같은 서비스 혹은 다른 서비스를 여러번 dispatch 가능하다. dispatched 된 각 서비스에 대하여 서로 다른 dispatch context 를 생성함에 의해서 말이다.
l 서버는 tpinit() 함수를 호출하거나 클라이언트로서 동작할 수 없다. 만약, 서버가 tpinit() 함수를 호출하면, tpinit() 함수는 -1 을 리턴하고 tperrno 를 TPEPROTO 로 설정한다. application-created 서버 쓰레드는 tpsetctxt() 함수를 호출하기 전에 ATMI 호출을 하지 못한다.
l 오직, 서버 dispatched 쓰레드만이 tpreturn() 또는 tpforward() 를 호출가능하다.
l 서버는 만약, application-created 쓰레드가 아직 어떠한 application context 와 Associated 되어 있다면 tpreturn() 함수 또는 tpforward() 함수를 실행할 수 없다. 그러므로, 서버 dispatched 쓰레드가 tpreturn() 함수를 호출하기 전에, 해당 Context 에 관련된 각 application-created 쓰레드는 TPNULLCONTEXT(-2) 또는 다른 valid context 를 tpsetctxt() 함수에 설정하여 호출해야 한다. 만약, 이 규칙을 위반하면, tpreturn() 함수 또는 tpforward() 함수는 userlog 에 메세지를 기록하고 TPESVCERR 를 호출자에게 리턴하며, 제어권을 main 서버 dispatch 루프에 돌려준다. Invalid tpreturn() 함수가 수행된 Context 에 있었던 쓸레드들은 Invalid context 에 위치하게 된다.
l 만약, tpreturn() 함수 또는 tpforward() 함수가 호출되었을 때, 현재 진행중인 ATMI Calls, RPC(Remote Procedure Call) calls, Conversations 가 있다면, tpreturn() 함수 또는 tpforward() 함수는 Userlog 에 메세지를 기록하고 호출자에게 TPESVCERR 오류를 리턴하며 제어권을 main 서버 dispatch 루프에 돌려준다.
l 서버 dispatched 쓰레드는 tpsetctxt() 함수를 호출할 수 없다.
l Single-contexted 서버와는 다르게, multicontexted 서버 쓰레드는 같은 서버에 의해 제공되는 서비스를 호출하는 것이 가능한다.
Initializaing and Terminating Servers and Server Threads
여러분의 서버와 서버 쓰레드를 초기화하고 종료하기 위해서는, 여러분은 BEA Tuxedo 시스템에서 제공되는 기본적인 함수들을 사용하거나 여러분 자신들이 만든 함수들을 사용할 수 있다.
|
동작 |
기본으로 사용하는 함수 |
|
서버 초기화 |
tpsvrinit() |
|
서버 쓰레드 초기화 |
tpsvrthrinit() |
|
서버 종료 |
tpsvrdone() |
|
서버 쓰레드 종료 |
tpsvrthrdone() |
Programming a Server to Create Threads
multicontexted 서버를 사용하는 대부분의 Applications 가 턱시도 시스템에 의해 만들어진 dispatched 서버 쓰레드만을 사용한다고 할지라도, 여러분은 Application 서버안에서 추가로 쓰레드를 만들 수 있다. 다음은 이러한 작업을 하는 데 사용하는 명령어를 제공한다.
l Creating Threads
여러분은 OS(운영체제) 쓰레드 함수들을 사용하여 Applicaion 서버안에서 추가로 쓰레드를 만들 수 있다. 이러한 쓰레드들은 BEA Tuxedo 시스템과 독립적으로 작업하거나, 서버 dispatched 쓰레드들과 같은 Context 에서 동작한다.
l Associating Threads with a Context
초기에, application-created 서버 쓰레드들은 어떠한 서버 dispatched Context 와도 Associated 되어 있지 않다. 그러나, 만약, 초기화되기전에 함수가 호출되면, 대부분의 ATMI 함수들은 내부적으로 tpinit() 함수를 수행한다. 서버가 tpinit() 함수를 호출하는 것이 금지되어 있으므로, 그러한 함수호출은 문제를 야기한다. 만약, 서버가 tpinit() 함수를 호출한다면, tpinit() 함수는 -1 를 리턴하고 tperrno 에 TPEPROTO 를 설정한다.
그러므로, application-created 서버 쓰레드는 어떠한 ATMI 함수를 호출하기 전에 기존에 존재하는 Context 에 그 자신을 Associate 해야 한다.
기존에 존재하는 Context 에 application-created 서버 쓰레드를 Associate 하기 위해서는, 여러분은 다음과 같은 절차를 구현하는 코딩을 해야 한다.
1. 서버 dispatched 쓰레드 A 는 tpgetctxt() 함수를 호출하여 현재 Context 에 대한 핸들을 얻는다.
2. 서버 dispatched 쓰레드 A 는 tpgetctxt() 함수에서 돌려준 핸들을 Application 쓰레드 B 에 넘겨준다.
3. Application 쓰레드 B 는 tpsetctxt() 함수를 사용하여 현재 Context 에 자신을 Associate 한다. 서버 dispatched 쓰레드 A 로 부터 받은 핸들을 지정해서 수행한다.
4. Application-created 서버 쓰레드는 tpreturn() 또는 tpforward() 함수를 호출할 수 없다. 원래의 dispatched 쓰레드가 tpretrun() 함수 또는 tpforward() 함수를 호출하기 전에, 현재 Context 에 있는 모든 Application-created 서버 쓰레드들은 TPNULLCONTEXT(-2) 또는 다른 Valid Context 로 스위칭해야 한다. 만약, 이러한 규칙이 지켜지지 않는다면, tpforward() 함수 또는 tpreturn() 함수 호출은 실패하고 서비스 오류가 호출자에게 보내진다.
Sample code for Creating an Application Thread in a Multicontexted Server
한 서버안에서 application 쓰레드를 만들 필요가 있는 프로그램에 대해서는, 다음과 코드 샘플은 하나의 서비스가 자신의 작업을 위해 다른 쓰레드를 만드는 multicontexted 서버를 보여준다.
OS(운영체제) 쓰레드 함수들은 OS(운영체제) 마다 다르다. 다음 예제는 POSIX 와 ATMI 함수들이 사용된다.
Note) 샘플을 단순화하기 위해, 오류 검사 코드는 포함되어 있지 않다. 또한, BEA Tuxedo 시스템에 의해 dispatched 된 쓰레드를 사용한 multicontexted 서버의 예제는 그러한 서버 프로그램은 thread-safe 프로그래밍 규칙이 사용된다면, Single-contexted 서버와 같은 방식으로 코딩되기 때문에 포함되어 있지 않다.
Code Sample for Creating a Thread in a Multicontexted Server
|
#include <pthread.h> #include <atmi.h>
void *withdrawalthread(void *);
struct sdate { TPCONTEXT_T ctxt; TPSVCINFO *svcinfoptr; };
void TRANSFER(TPSVCINFO *svcinfo) { struct sdate transferdata; pthread_t withdrawlthreadid;
tpgetctxt(&transferdata.ctxt, 0);
transferdata.svcinfoptr = svcinfo;
pthread_create(&withdrawlthreadid, NULL, withdrawalthread, &transferdata);
tpcall(“DEPOSIT”, ...);
pthread_join(withdrawalthreadid, NULL);
tpreturn(TPSUCCESS, ...); }
void *withdrawalthread(void *arg) { tpsetctxt(arg->ctxt, 0); tpopen(); tpcall(“WITHDRAWAL”, ...); tpclose(); return(NULL); } |
위 예제는 원래 dispatched 쓰레드에서 DEPOSIT 서비스를 그리고 application-created 쓰레드에서 WITHDRAWAL 서비스를 호출하여 자금이체를 수행하는 프로그램을 보여준다.
이 예제는 사용되는 RM(Resource Manager) 가 mixed model 를 허용한다는 가정하에 작성된 것이다.
즉, 특정 데이타베이스 Connection 에 모든 쓰레드가 Associate 되어지는 것이 아니라 일부 다수 쓰레드들은 특정 데이타베이스 Connection 에 Associate 되는 model 인 경우이다.
그러나, 대부분의 RM(Resource Manager) 는 그러한 mixed model 을 지원하지 않는다.
이 예제를 코딩하는 간단한 방법은 application-created 쓰레드 사용을 하지 않는 것이다.
이 예제에 있는 2 번의 tpcall() 함수 호출에 의해 제공되어지는 같은 동시성(Concurrency)를 얻기 위해서는 서버 dispatched 쓰레드에 2 번의 tpacall() 함수와 2 번의 tpgetrply() 함수호출로 대체해야 한다.
Writing a Multithreaded Client
l Multithreaded 클라이언트에 대한 코딩 규칙
l 다중 Context 에 대한 클라이언트 초기화
l Multithreaded 환경에서 응답 얻기
l Multithreaded and/or Multicontexted 환경에서 환경변수 사용하기
l Multithreaded 클라이언트에서 Per-context 함수와 데이타 구조체 사용
l Multithreaded 클라이언트에서 Per-process 함수와 데이타 구조체 사용
l Multithreaded 클라이언트에서 Per-thread 함수와 데이타 구조체 사용
l Multithreaded 클라이언트에 대한 샘플 코드
Note) BEA Tuxedo 시스템은 Multithreaded COBOL Applications 를 지원하지 않는다.
Coding Rules for a Multithreaded Client
multithreaded 클라이언트 코딩에시 다음과 같은 규칙을 명심해야 한다.
l 일단, Conversation 이 시작되었다면, 해당 프로세스에 있는 임의의 쓰레드는 해당 Conversation 에서 작업할 수 있다. 핸들과 Call Descriptor 는 같은 프로세스내에 동일한 Context 안에서 호환가능한다. 하지만, Context 간이나 프로세스간에는 불가능한다. 핸들과 Call Descriptor 는 그들이 원래 할당받은 application context 내에서만 사용되어질 수 있다.
l 같은 프로세스의 같은 Context 내에서 작동하는 임의의 쓰레드는 해당 쓰레드가 tpacall() 함수를 호출했든, 안했든지에 관계없이, 이전에 호출된 tpacall() 함수에 대한 응답을 받기 위해 tpgetrply() 함수를 호출할 수 있다.
l 트랜잭션은 오로지, 하나의 쓰레드에 의해 commit 또는 abort 될 수 있다. 해당 트랜잭션을 시작한 쓰레드와는 관계없이 수행한다. 모든 RPC(Remote Procedure Call) 와 Conversations 는 트랜잭션이 Commit 되기전에 완료되어야 한다. 만약, application 이 RPC(Remote Procedure Call) 또는 Conversations 가 진행중인 경우에 tpcommit() 함수를 호출한다면, tpcommit() 함수는 해당 트랜잭션을 abort 하고 -1 값을 리턴하고 tperrno 에 TPEABORT 값을 설정한다.
l tpcall(), tpacall(), tpgetrply(), tpconnect(), tpsend(), tprecv() 그리고 tpdiscon() 함수들은 아직 트랜잭션이 committing 또는 aborting 중인지를 확신할 수 없다면 트랜잭션 모드로 호출해서는 안된다.
l 같은 Context 에서 동시에 2 개의 tpbegin() 함수가 호출될 수 없다.
l tpbegin() 함수는 이미 현재 트랜잭션 모든인 Context 에서 호출될 수 없다.
l 만약, 여러분이 클라이언트를 사용하고 하나이상의 도메인에 연결을 하고자 한다면, 여러분은 tpinit() 함수 호출전에 TUXCONFIG 또는 WSNADDR 환경변수의 값을 수작업으로 변경해야 한다. 만약, multiple 쓰레드가 그러한 Action 을 한다면, 여러분은 tpinit() 함수호출과 해당 환경변수의 동기화를 맞춰야 한다. 클라이언트에 있는 모든 Application Association 은 다음과 같은 규칙을 따라야 한다.
ü 모든 Association 은 같은 배포판의 BEA Tuxedo 시스템에서 만들어져야 한다.
ü 특정 클라이언트에 있는 모든 Application Association 이 Native 클라이언트로 만들어져야 하거나 모든 Application Association 이 WorkStation 클라이언트로 만들어져야 한다.
l Application 과 조인하기 위해, multithreaded WorkStation 클라이언트는 항상, TPMULTICONTEXTS 플래그를 설정하여 tpinit() 함수를 호출해야 한다. 물론, 해당 클라이언트가 Single-context 모드에서 운영되어도 마찬가지이다.
Initializing a Client to Multiple Contexts
클라이언트가 하나 이상의 Context 에 조인하기 위해서는, TPINIT 데이타 Structure 의 flags 멤버에 TPMULTICONTEXTS 플래그를 설정하여 tpinit() 함수를 호출해야 한다.
임의의 한 프로세스내에서, tpinit() 함수에 대한 모든 호출이 TPMULTICONTEXTS 플래그를 포함하거나 tpnit() 함수에 대한 어떠한 호출도 해당 플래그를 포함하지 않아야 한다. 이 규칙에 대한 예외는 클라이언트의 모든 Application Association 이 tpterm() 함수에 의해 모두 종료되었다면, 해당 프로세스가 tpinit() 함수의 Next Call 시 TPMULTICONTEXTS 플래그의 설정여부가 Option 이 되는 상태로 복귀하는 경우이다.
tpinit() 함수가 TPMULTICONTEXTS 플래그를 설정하여 호출되어진다면, 새로운 Application Association 이 만들어지고 현재 Association 으로 설정된다. 새로운 Association 이 만들어지는 BEA Tuxedo 도메인은 TUXCONFIG 또는 WSENVFILE/WSNADDR 환경변수에 값에 의해 결정되어 진다.
클라이언트 쓰레드가 TPMULTICONTEXTS 플래그 없이 tpinit() 함수를 호출한다면, 해당 클라이언트에 있는 모든 쓰레드들은 Single-context 상태에 놓영지게 된다.(TPSINGLECONTEXT)
실패시, tpinit() 함수는 호출 쓰레드을 원래 Context 에 그냥 놓아둔다. 즉, tpinit() 함수 호출이 발생하기전에 그것이 작업중인 Context 상태를 의미한다.
해당 Context 내에 있는 임의의 쓰레드가 여전히 작업중이면, 주어진 Context 로 부터 tpterm() 함수를 호출하지 말아야 한다. 이러한 모든 다른 조건하에서 tpterm() 함수를 호출하여 발생하는 Context 상태에 대하여는 Multicontext State Transitions 이 붙은 도표를 참조한다.
Context State Changes for a Client Thread
Multicontext Application 에서, 여러가지 함수호출은 해당 호출 쓰레드와 호출 프로세스의 같은 Context 에서 활동중인 다른 쓰레드에 대한 Context 상태 변경을 초래한다.
다음 그림은 tpinit(), tpsetctxt(), tpterm() 함수 호출로 부터 발생되는 Context 상태 변화를 도식화한다.
참고로, tpgetctxt() 함수는 어떠한 Context 상태 변경을 발생시키지 않는다.
Multicontext State Transitions
|
|
Note) tpterm() 함수가 multicontext 상태(TPMULTICONTEXTS)로 운영되는 쓰레드에서 호출된다면, 호출하는 쓰레드는 Null Context 상태(TPNULLCONTEXT)에 놓여지게 된다. 종료되는 Context 와 Associated 된 모든 다른 쓰레드는 Invalid Context 상태로 스위칭된다.
다음 도표는 tpinit(), tpsetctxt(), tpterm() 에 의해 발생할 수 있는 가능한 모든 Context 상태 변화를 리스트한다.
|
When this function is executed . . . |
Then a thread in this context state results in . . . | |||
|
Null Context |
Single Context |
Multicontext |
Invalid Context | |
|
tpinit() without TPMULTICONTEXTS |
Single context |
Single context |
Error |
Error |
|
tpinit() with TPMULTICONTEXTS |
Multicontext |
Error |
Multicontext |
Error |
|
tpsetctxt(3c) to TPNULLCONTEXT |
Null |
Error |
Null |
Null |
|
tpsetctxt(3c) to context 0 |
Error |
Single context |
Error |
Error |
|
tpsetctxt(3c) to context > 0 |
Multicontext |
Error |
Multicontext |
Multicontext |
|
Implicit tpinit() |
Single context |
N/A |
N/A |
Error |
|
tpterm() in this thread |
Null |
Null |
Null |
Null |
|
tpterm() in a different thread of this context |
N/A |
Null |
Invalid |
N/A |
Getting Replies in a Multithreaded Environment
tpgetrply() 함수는 단지 tpacall() 함수 호출에 대한 응답을 수신한다. tpcall() 함수 호출은 서로 별개이며 multithreading 또는 multicontexting 레벨에 관계없이 tpgetrply() 함수로 해당 응답을 수신할 수 없다.
tpgetrply() 함수는 오로지, 하나의 Context 에서만 작동한다. 그 Context 는 해당 함수가 호출되어지는 Context 이다. 그러므로, 여러분이 TPGETANY 플래그를 설정하여 tpgetrply() 함수를 호출하다면, 같은 Context 에서 만들어진 핸들만이 고려의 대상이 된다. 따라서, 하나의 Context 에서 만들어진 핸들은 다른 Context 에서 사용되어질 수 없지만, 같은 Context 내에 있는 임의의 쓰레드에서 사용되어질 수 있다.
tpgetrply() 함수를 multithreaded 환경에서 사용할 때, 다음과 같은 제약사항이 적용된다.
l 같은 Context 내에 있는 다른 쓰레드가 같은 핸들에 대해서 tpgetrply() 함수를 호출하고 있는 중에 한 쓰레드가 같은 핸들에 대해서 tpgetrply() 함수를 호출하면, 해당 tpgetrply() 함수 호출은 -1 값을 리턴하고 tperrno 에 TPEPROTO 를 설정한다.
l 같은 Context 내에 있는 다른 쓰레드가 TPGETANY 플래그를 설정하여 tpgetrply() 함수를 호출하고 있는 중에 한 쓰레드가 특정 핸들에 대해서 tpgetrply() 함수를 호출하면, 해당 호출은 -1 값을 리턴하고 tperrno 에 TPEPROTO 를 설정한다.
ü 만약, 같은 Context 내에 있는 쓰레드가 특정 핸들에 대해서 tpgetrply() 함수를 호출중인 상태에서, TPGETANY 플래그를 설정한 tpgetrply() 함수를 다른 쓰레드가 호출하는 경우에도 동일한 현상이 발생한다. 이러한 제약사항은 특정 핸들에 대해서 대기하고 있는 쓰레드가 임의의 핸들에서 대기하고 있는 다른 쓰레드에 의해 응답이 수신되는 것을 방지한다.
l 주어진 시간에, 특정 Context 에 있는 쓰레드 하나만이 TPGETANY 플래그를 설정하여 tpgetrply() 함수를 호출할 수 있다. 같은 Context 에 있는 두번째 쓰레드가 유사한 ATMI Call 이 Out standing 상태에서 TPGETANY 플래그를 설정하여 tpgetrply() 함수를 호출하면, 해당 Second Call 은 -1 값을 리턴하고 tperrno 에 TPEPROTO 를 설정한다.
Using Environment Variables in a Multithreaded and/or Multicontexted Environment
multicontexeted and/or multithreaded 환경에서 BEA Tuxedo 응용 프로그램이 실행된다면, 다음과 같은 고려사항이 환경변수 사용에 적용된다.
l 프로세스는 처음에 OS(운영체제)로 부터 그의 환경을 상속받는다. 환경변수를 지원하는 플랫폼, 즉, 그러한 환경변수는 프로세스당 구성한다. 그러므로, context 환경설정에 근거한 Applications 는 OS(운영체제) 함수대신 tugetenv() 함수를 사용해야 한다.
Note) 환경변수는 OS(운영체제) 환경을 인식하지 못하는 그러한 OS(운영체제)에 대해서는 처음에 공백상태이다.
l 많은 환경변수들은 프로세스별 또는 Context 별로 BEA Tuxedo 시스템에 의해 잃혀지고 BEA Tuxedo 시스템안에 Cached 된다. 일단 프로세스안에 Cached 그러한 환경변수에 대한 변경은 아무런 효과가 없다. 즉, 변경된 환경변수의 값이 적용되지 않는다.
|
Caching 이 발생하는 위치 |
대상 환경변수 |
|
Context 별 |
TUXCONFIG |
|
FIELDTBLS, FIELDTBLS32 | |
|
ULOGPFX | |
|
VIEWDIR, VIEWDIR32 | |
|
VIEWFILES, VIEWFILES32 | |
|
WSNADDR | |
|
WSDEVICE | |
|
WSENV | |
|
프로세스 별 |
TMTRACE |
|
TUXDIR | |
|
ULOGDEBUG |
l tuxputenv() 함수는 전체 프로세스의 환경변수에 영향을 준다.
l 여러분이 tuxreadenv() 함수를 호출할 때, 그것은 환경변수를 가지고 있는 파일을 읽어서 그것들을 프로세스를 위한 환경변수에 추가한다.
l tuxgetenv() 함수는 현재 Context 에 있는 요청된 환경변수의 현재 값을 리턴한다. 처음에 모든 Context 는 같은 환경변수 값을 가지지만, 특정 Context 에 지정된 환경변수의 사용은 다른 Context 가 서로 다른 환경변수 설정값을 가지도록 한다.
l 만약, 클라이언트가 하나 이상의 도메인에 Initialize 하고자 한다면, 해당 클라이언트는 tpinit() 함수를 호출하기 전에 해당 함수에 대하여 각각, TUXCONFIG, WSNADDR 또는 WSENVFILE 환경변수의 값을 변경해야 한다. 만약, 그러한 Application 이 multithreaded 라면, mutex 또는 다른 application-defined Concurrency 제어(Control)가 다음과 같은 사항을 보증하기 위해 아마도 필요하게 될 것이다.
ü 적합한 환경변수가 재설정되야 한다.
ü tpinit() 함수에 대한 호출이 임의의 다른 쓰레드에 의해 환경변수 재설정 작업이 없이 호출되었는지를 확인해야 한다.
l 클라이언트가 턱시도 시스템에 접속하고자 할 때, WSENVFILE and/or machine 환경파일이 읽혀지고 오직, 해당 Context 내에 있는 환경에만 영향을 미친다. 해당 프로세스에 대하여 앞에서 설정된 환경변수는 환경파일안에서 재설정되는 시점까지는 해당 Context 에 대하여 그대로 잔존해 있다.
Using Per-context Functions and Data Structures in a Multithreaded Client
다음의 ATMI 함수들은 단지, 그들이 호출되는 Application Context 에 영향을 미치는 함수들이다.
tx_set_transaction_control(3c)
tx_set_transaction_timeout(3c)
Note) tpbroadcast() 함수에 대하여, Broadcase 메세지는 특정 Application Association 으로 부터 온 것으로 식별되어질 수 있다. tpnotity() 함수에 대하여도, Notification 은 특정 Application Association 으로 부터 온 것으로 식별되어 질 수 있다. tpinit() 함수에 관한 참고사항은 “Using per-process Functions and Data Structures in a Multithreaded Client” 부분을 본다.
만약, tpsetunsol() 함수가 아직 Context 에 Associated 되지 않은 쓰레드에서 호출된다면, tpinit() 함수를 사용하여 새롭게 만들어지는 Context 에 대하여, 프로세스 기본 unsolicited 메세지 핸들러가 만들어진다.
특정 Context 는 해당 Context 가 Active 라면 tpsetunsol() 함수를 다시 호출하여 해당 Context 에 설정된 unsolicited 메세지 핸들러를 변경할 수 있다.
프로세스 기본 unsolicited 메세지 핸들러는 현재 Context 에 Associated 되지 않은 쓰레드에서 다시, tpsetunsol() 함수를 호출하여 변경할 수 있다.
l CLIENTID, Client Name, User Name, Transaction ID 그리고 TPSVCINFO 데이타 Structure 의 내용은 같은 프로세스안에서 Context 마다 다를 수 있다.
l Asynchronous Call 과 Connection Descriptors 은 그들이 생성된 Context 안에서만 유효하다. Unsolicited Notification Type 은 Per-context 이다. 비록, Signal-based notification 이 multiple context 내에서 사용할 수 없을지라도, 각 Context 는 다음 3 가지 선택사항중 하나를 선태할 수 있다.
ü Unsolicited 메세지를 무시
ü Dip-in Notification 을 사용
ü Dedicated Thread Notification 을 사용
Using Per-process Functions and Data Structures in a Multithreaded Client
다음과 같은 BEA TUXEDO 함수는 그들이 생성된 프로세스 전체에 대하여 영향을 미친다.
tpadvertise()
tpalloc()
tpconvert()
tpfree()
tpinit() -
tprealloc()
tpsvrdone()
tpsvrinit()
tptypes()
tpunadvertise()
tuxgetenv()
tuxputenv(0
tuxreadenv()
Usignal
Single-context mode, multicontext mode 또는 uninitialized mode 의 결정은 프로세스 전체에 영향을 미친다.
버퍼 타입 Switch, View Cache 그리고 환경변수 값들 또한 Per-Process 함수이다.
Using Per-thread Functions and Data Structures in a Multithreaded Client
호출하는 쓰레드는 다음과 같은 함수 사용에 의해 영향을 받는다.
CATCH
tperrordetail()
tpgetctxt()
tpgprio()
tpsetctxt()
tpsprio()
tpstrerror()
tpstrerrordeatil(0
TRY
Uunix_err()
Ferror, Ferror32(), tperrno, tpurcode 그리고 Uunix_err 변수들 또한 각 쓰레드에 지정된다.
현재 Context 에 대한 Identitiy 는 각 쓰레드에 지정된다.
Sample Code for a Multithreaded Client
다음 예제는 ATMI Calls 를 사용하여 multithreaded 클라이언트를 보여준다. 쓰레드 함수는 각 OS(운영체제)마다 다르다. 이 예제에서는, POSIX 함수가 사용된다.
Note) 이 예제를 간단화하기 위해, 오류 검사 코드는 포함되어 있지 않다.
Sample Code for a Multithreaded Client
|
#include <stdio.h> #include <pthread.h> #include <atmi.h>
TPINIT * tpinitbuf;
int timeout = 60; pthread_t withdrawalthreadid, stockthreadid; TPCONTEXT_T ctxt;
void * stackthread(void *); void * withdrawalthread(void *);
main() { tpinitbuf = tpalloc(“TPINIT”, NULL< TPINITNEED(0)); tpinitbuf->flags = TPMULTICONTEXTS; tpinit(tpinitbuf);
tpgetctxt(&ctxt, 0);
tpbegin(timeout, 0); pthread_create(&withdrawalthreadid, NULL, withdrawalthread, NULL); tpcall(“DEPOSIT”, ...); pthread_join(withdrawalthreadid, NULL); tpcommit(0); tpterm();
pthread_join(stockthreadid, NULL);
printf(“$%9.2f has been transfoerred from your savings account to your checking account.\n”, ...); printf(“At the current BEA stock price of $%8.3f, you could purchase %d shares.\n”, ...); exit(0); }
void * stockthread(void *arg) { tuxputenv(“TUXCONFIG=/home/users/xyz/stockconf”);
tpinitbuf->flags = TPMULTICONTEXTS; tpinit(tpinitbuf);
tpcall(“GETSTOCKPRICE”, ...); tpterm();
return(NULL); }
void * withdrawalthread(void *arg) { pthread_create(&stockthreadid, NULL, stockthread, NULL); tpsetctxt(ctxt, 0); tpcall(“WITHDRAWAL”, ...);
return(NULL); } |
Writing a Multithreaded Server
Multithreaded 서버는 또한, 항상, multicontexted 이다. Multithreaded 서버를 작성하기 위한 자세한 정보는 Writing Code to Enable Multicontexting and Multithreading in a Server.
Compiling Code for a Multithreaded/Multicontexted Applicaion
buildserver 와 buildclient 처럼, 실행파일을 만드는 BEA Tuxedo 시스템에 의해 제공되는 프로그램은 자동적으로 임의의 필요한 컴파일러 플래그를 포함한다. 만약, 여러분이 이 툴(Tool)을 사용한다면, 여러분은 컴파일시에 임의의 플래그를 설정할 필요가 없다.
그러나, 만약, 여러분의 .c 파일을 .o 파일로 최종 컴파일전에 컴파일한다면, 여러분은 플랫폼에 따른 컴파일러 플래그를 설정할 필요가 있다. 그러한 플래그는 Single 프로세스에 링크되는 모든 코드에 대해 똑같이 설정되어야 한다.
만약, 여러분이 mutltithreaded 서버를 만들려고 하면, 여러분은 -t 옵션을 설정하여 buildserver 명령을 실행해야 한다. 이 옵션은 multithreaded 서버에 대해서는 필수사항이다. 만약, 여러분이 그것을 Build 시에 지정하지 않았다면, 턱시도 구성화일의 MAXDISPATCHTHREADS 의 값이 1 보다 큰 경우 해당 서버를 부팅할 때, 경고 메세지가 User Log 에 기록되고 해당 서버는 Single_threaded 처럼 동작하는 서버로 변경된다.
multithreaded 환경에서 여러분이 .c 파일을 .o 파일로 컴파일할 때, 필요한 OS(운영체제) 지정 컴파일러 파라미터를 확인하기 위해서는 해당 파일을 컴파일할 때, -v 옵션을 설정하여 buildclient 또는 buildserver 명령을 실행하면 된다.
Testing a Multithreaded/Multicontexted Application
l Testing Recomendations for a Multithreaded/Multicontexted Application
l Troubleshooting a Multithreaded/Multicontexted Applicaiton
l Error Handling for a Multithreaded/Multicontexted Application
Testing Recomendations for a Multithreaded/Multicontexted Application
l multi-processor 사용
l 만약, OS(운영체제)가 지원한다면, multithreaded debugger 사용
l 시간 경과에 따른 문제점을 파악하기 위한 Stress Test 실시
Troubleshooting a Multithreaded/Multicontexted Applicaiton
여러분이 발생할 수 있는 가능한 오류의 원인을 알고자 할 때, 여러분이 TPMULTICONTEXTS 플래그를 설정여부를 먼저 확인하는 권고하는 방법이다. 오류는 종종 이 플래그를 설정하지 않았거나 제대로 설정하지 않아서 발생한다.
Improper Use of the TPMULTICONTEXTS Flag to tpinit()
만약, 프로세스가 TPMULTICONTEXTS 플래그 설정이 허용되지 않는 상태에서 TPMULTICONTEXTS 플래그를 사용하거나 또는 해당 플래그 설정이 필요한 상태에서 해당 플래그를 사용하지 생략하였다면, tpinit() 함수는 -1 를 리턴하고 tperrno 에 TPEPROTO 를 설정한다.
Calls to tpinit() Without TPMULTICONTEXTS
tpinit() 함수가 TPMULTICONTEXTS 플래그 없이 호출된다면, 그것은 마치 Single-contexted application 에서 동작하는 것처럼 작동한다. 일단, tpinit() 함수가 호출되어 졌다면, TPMULTICONTEXTS 플래그가 없는 tpinit() 함수에 대한 연속호출은 아무런 Action 없이 성공한다. 이것은 심지어 Application 안에 있는 TUXCONFIG 또는 WSNADDR 환경변수의 값을 변경되었더라도 마찬가지이다.
TPMULTICONTEXTS 플래그 없이 tpinit() 함수를 호출하는 것은 multicontexted 모드에서는 허용되지 않는다.
만약, 클라이언트가 아직 Application 에 조인되지 않은 상태에서 내부적으로 tpinit() 함수가 호출된다면(tpinit() 함수를 호출하는 다른 함수호출의 결과로서), BEA Tuxedo 시스템은 해당 Action 을 TPMULTICONTEXTS 플래그 없이 tpinit() 함수를 호출한 것과 같이 해석한다. 왜냐하면, tpinit() 함수의 다음호출에서 어떤 플래그가 사용되어야 하는지를 결정하기 위해서이다.
대부분의 ATMI 함수들에 대해서, 함수가 multicontext 모드에서 이미 동작중인 프로세스의 Context 와 Associated 되지 않은 쓰레드에서 호출된다면, 해당 ATMI 함수는 tperrno 에 TPEPROTO 를 설정하면서 실패한다.
Insuffiecnt Thread Stack Size
어떤 OS(운영체제) 시스템에서, OS(운영체제) 기본 쓰레드 Stack 크기는 BEA Tuxedo 시스템을 사용하기 위해서는 부족한다. 이러한 경우에 속하는 시스템은 Compaq Tru64 UNIX 와 UnixWare 2 OS(운영체제)이다.
만약, 기본 쓰레드 Stack 크기 파라미터가 사용된다면, 해당 플랫폼의 Applications 는 메인 쓰레드가 아닌 다른 임의의 쓰레드에 의해 계속적인 Stack 사용이 필요로 하는 함수를 호출하게 되면 코아 덤프(Core Dump) 가 발생한다.
종종, 코아(Core) 파일은 부족한 Stack 크기가 해당 문제의 원인이라는 사실에 대한 명확한 어떠한 실마리도 주지 않는다.
BEA Tuxedo 시스템이 자신 안에서 쓰레드, 즉, server-dispatched 쓰레드 또는 클라이언트 unsolicited 메세지 쓰레드를 만든다면, 그것은 해당 플랫품의 기본 Stack 크기 파라미터를 충분한 값으로 조정할 수 있다.
그러나, application 이 자신 안에서 쓰레드를 만든다면, 해당 Application 은 충분한 Stack 크기를 지정해야 한다. 최소한 128 K 정도의 크기가 BEA Tuxedo 시스템을 접근하는 임의의 쓰레드에 대해서 사용되어야 한다.
Compaq Tru64 UNIX 와 POSIX 쓰레드가 사용되는 다른 시스템에서, 쓰레드 Stack 크기는 pthread_create() 함수전에 pthread_attr_setstacksize() 함수에 의해 지정되어져야 한다.
UnixWare 시스템에서, 쓰레드 Stack 크기는 thr_create() 함수에 대한 인자로 지정되어져야 한다.
이 주제에 대하여 자세한 설명은 여러분의 OS(운영체제) 시스템 문서를 참조하길 바랍니다.
Error Handling for a Multithreaded/Multicontexted Application
오류는 User Log 에 기록되어 진다. 각 오류에 대해서, Single-context 모드 또는 multicontext 모드인지에 따라서 다음과 같은 정보가 기록되어 진다.
|
process_ID.thread_ID.context_ID |
4. 참고사항
Ø 자세한 설명은 TUXEDO Administration Guide 를 참고하기 바랍니다.
'▶ Tuxedo > 기술자료' 카테고리의 다른 글
| TUXEDO/Q 개념과 qmadmin 사용방법 (0) | 2012.03.16 |
|---|---|
| TUXEDO MP Mode Migration 사용방법 (0) | 2012.03.16 |
| Tuxedo 서비스를 서버 프로세스로 Grouping하는 방안 (0) | 2012.02.29 |
| PENTRY 에러 발생시 (0) | 2012.02.29 |
| P-Project 관련 조합 H/W 선정을 위한 BMT에서 발생한 문제 (0) | 2012.02.29 |