QUESTION
=========

alert 로그에 아래와 같은 pending 관련 메시지가 기록되어 있었고
dba_2pc_pending 테이블을 조회해 본 결과 2159건이 존재하였었습니다.
현재 pending은 모두 해결되었지만, 왜 pending이 발생하는지 원인을 알고 싶습니다.


Fri Jan 18 01:59:48 2008
DISTRIB TRAN 28.4249535741533200000000000000000000000000000000000000000000000000000
6E631478F4FBF00000045
is local tran 3.5.1878541 (hex=03.05.1caa0d)
insert pending prepared tran, scn=8817886848927 (hex=805.1303679f)
DISTRIB TRAN 28.4249535741533200000000000000000000000000000000000000000000000000000
6E631478F4FBF00000046
is local tran 4.21.1886262 (hex=04.15.1cc836)


ANSWER
=======

1. session timeout (sestm) : XA transaction은 각 단계별로 xa_open, xa_end, xa_prepare, .. 등의 call을 하게 되는데,
각 call이 처리되는 동안 transaction이 session에 attatch되고, 이후는 detatch되어 detatched branch로 관리됩니다.
이 detatched 상태로 얼마만큼 대기할것인지를 결정하는 timeout입니다.

2. session timeout 이상 동안 아무 처리가 안되면 아래 두가지 중 하나로 처리됩니다.

(1) prepared 단계가 아닌 경우
pmon이 cleanup을 하게됩니다.
(2) prepared 단계에서 detatched branch 의 경우는,
pmon이 직접 cleanup을 하지 못하고, smon에게 in-doubt transaction이 있음을 알립니다.
smon은 이 indoubt transaction을 dba_2pc_pending에 insert를 하고, reco process가 처리하도록 합니다.
이 in-doubt transaction이 non-XA인 경우 reco가 cleanup하게 되지만,
XA인 경우는 oracle이 cleanup을 하지 못하고, TM이 처리하도록 합니다.


위의 로직을 고객사 상황에 적용하면 prepared tx 들에대해 어플리케이션에서 commit/rollback call 이
session timeout 동안 호출되지 않아서 모두 timeout 되어 dba_2pc_pending 에 insert 된 것입니다.

어플리케인 로그 체크하셔서 session timeout 동안 왜 commit/rollback 을 안했는지 확인하셔야합니다.

참고문서
Note.33293.1 Ext/Pub Common Issues When Configuring Oracle XA