Timeout occurs with the application server
You are trying to edit an object, but after a delay an error is issued by WebSphere Application Server Liberty
Base referring to a timeout:
AWSJCO005E WebSphere Application Server Liberty
Base has given the following error:
CORBA NO_RESPONSE 0x4942fb01 Maybe; nested exception is:
org.omg.CORBA.NO_RESPONSE:
Request 1685 timed out vmcid:
IBM minor code: B01 completed: Maybe.Cause and solution:
In this case the object you are trying to access is locked from outside IBM Workload Scheduler, maybe by the database administrator or an automatic database function. So the application waits to get access until it is interrupted by the application server timeout.
- DB2®
- By default, both DB2® and WebSphere Application Server Liberty
Base have the same length timeout, but as
the WebSphere Application Server Liberty
Base action starts before the DB2® action, it is normally the WebSphere Application Server Liberty
Base timeout that is logged. If one or both of the timeouts have been modified from the default values, and the DB2® timeout is now shorter, the following message is issued:
AWSJDB803E An internal deadlock or timeout error has occurred while processing a database transaction. The internal error message is: "The current transaction has been rolled back because of a deadlock or timeout. Reason code "68". - Oracle
- There is no corresponding timeout on Oracle, so the Dynamic Workload Console hangs.
To resolve the problem, get the database administrator to check if the object in question is locked outside IBM Workload Scheduler. If it is, take the appropriate action to unlock it, if necessary asking the database administrator to force unlock the object.
If the object is not locked outside IBM Workload Scheduler, retry the operation. If the problem persists contact IBM® Software Support for assistance.