유선상으로 이야기드린 것처럼,
Tuxedo는 XA spec에 있는 XA function에 의해 communicate하는 것이지,
특정 DB(RM)의 에러 값에 의해 동작하는 것이 아닙니다.
그래서 TUXWA4ORACLE은
XA function 수행 시 특정 XA return value에 동작하도록 한 것으로,
옛날에 Oralcle DB의 bug에 대한 workaround로
환경변수 TUXWA4ORACLE를 설정하면,
XAER_RMFAIL에 대해 xa_open() 수행전 xa_close()를 수행하고 xa_open()을 수행토록 한 것입니다.
일예로 xa_start()시 XAER_RMFAIL이 return되면,
내부적으로 xa_start() = XAER_RMFAIL -> xa_open() -> xa_start()에서
TUXWA4ORACLE를 설정하면 xa_start() = XAER_RMFAIL -> xa_close() -> xa_open() -> xa_start()가 됩니다.
생각하셔야 될 것은,
위 동작은 XA function에서 그리고 특정 에러가, 여기서는 XAER_RMFAIL, return되었을 때의 특정 동작이라는 것입니다.
DB 전체가 restart했들 때와 같이 특정 상황을 전제로 사용하는 것은 무리가 있을 수 있습니다.
해당 시점에 각각의 connection을 각각 갖고 있는 process 모두가 같은 수행 부분에 있지는 않을 것이고,
그에 따라 process별 return value가 다를 수 있는데...
또한 DB 전체 restart시에 항상 XAER_RMFAIL일런지...
WAS와 같이 모든 connection을 connection pool에 두어,
일시에 connection을 refresh하는 형태라면 모르겠지만, Tuxedo의 경우는 좀 다른 것으로 판단됩니다.
위 경우가 아니라 특정 경우면,
TMTRACE를 통해 어떤 XA fuction에서 수행 중에,
그리고 XAER_RMFAIL이 return되었는지등을 확인해 보시면 될 것입니다.
'▶ Tuxedo > 기술자료' 카테고리의 다른 글
▶ Tuxedo AP 서버가 비정상 종료한 경우 (0) | 2012.02.23 |
---|---|
Tuxedo 환경정보에 GW_VALIDATE_HOST=YES 옵션 (0) | 2012.02.23 |
Tuxedo 관련 환경변수 (0) | 2012.02.23 |
사용 중인 tmadmin 강제로 kill (0) | 2012.02.23 |
Thread 모니터링 (0) | 2012.02.23 |