APAR status
Closed as program error.
Error description
The following exception is thrown as a result of a commit
request: org.omg.CORBA.OBJECT_NOT_EXIST: SERVANT_NOT_FOUND
This exception is thrown on server B as a result of a
commit request being sent from server A during recovery
processing (and then on a retry thread). Server A is doing this
because it has a record in its transaction log that shows an
active transaction - the tran has in fact committed on
delinquency. This condition can arise if server A had failed at
any time with an active transaction. The problem starts when
server A is cleanly shutdown. At this point the
transaction logs are emptied. Now when the server starts up
again, the transaction service thinks its a cold start and
recreates the tranlog information. Part of this information is
the key that represents the servant. Now when server A comes
back up, it tries to talk to the servant using a key stored in
its transaction log. Hence the mis-match - the keys are
different.
Local fix
1. Back up the tranlog directories for every server (just as a
failsafe)
2. Close down cleanly every server
3. Delete the tranlog contents or directories for every server
(This step is not our usual recommendation for tranlog
problems).
4. Restart all the servers.
Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Users of *
* distributed transactions. *
****************************************************************
* PROBLEM DESCRIPTION: The following exception is thrown as *
* a result of a remote commit request: *
* ORG.OMG.CORBA.OBJECT_NOT_EXIST: *
* SERVANT_NOT_FOUND *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The following exception is thrown as a result of a commit
request: org.omg.CORBA.OBJECT_NOT_EXIST: SERVANT_NOT_FOUND
This exception is thrown on server B as a result of a
commit request being sent from server A during recovery
processing (and then on a retry thread). Server A was doing
this because it had a record in its transaction log that showed
an active transaction - the transaction had in fact committed
on server B.
This condition can arise if server A had failed at any time
with an active transaction.
The problem starts when server B is cleanly shutdown. At this
point its transaction logs are emptied. Now when the server
starts up again, the transaction service thinks its a cold
start and recreates the tranlog information. Part of this
recreated information is the key that represents the servant.
Now when server A comes back up, it tries to talk to the
servant using a key stored in its transaction log. Hence the
mis-match - the keys are different.
Problem conclusion
Classes JBrokerSupport, ControlSet, EventCommit will be
changed to handle the case when the subordinate server clears
its logs. A new class ControSethelp has also been
introduced to resolve this fix.
The fix for this APAR is currently targeted for inclusion in
fixpack 5.02.13. Please refer to the Recommended Updates page
for delivery information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix Comments
APAR information |
APAR number |
PK06716 |
Reported component name |
WAS NETWRK DEPL |
Reported component ID |
5630A3601 |
Reported release |
10A |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2005-06-02 |
Closed date |
2005-07-11 |
Last modified date |
2005-07-11 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
|
Fix information |
Fixed component name |
WAS NETWRK DEPL |
Fixed component ID |
5630A3601 |
Applicable component levels |
R003 PSY |
UP |
R00A PSY |
UP |
R00H PSY |
UP |
R00I PSY |
UP |
R00P PSY |
UP |
R00S PSY |
UP |
R00W PSY |
UP |
R103 PSN |
UP |
R10A PSN |
UP |
R10H PSN |
UP |
R10I PSN |
UP |
R10P PSN |
UP |
R10S PSN |
UP |
R10W PSN |
UP |
|