SchedulerStatus bean throws
com.ibm.ejs.persistence.OptimisticUpdateFailureException
|
Technote
(troubleshooting)
Problem(Abstract)
|
You start your WebSphere Commerce server and notice the
following exception.
CNTR0021E: EJB threw an unexpected (non-declared) exception while invoking
a method on bean
"BeanId(WC_demo#Enablement-BaseComponentsData.jar#SchedulerStatus,
instanceReferenceNumber=6707593 )". Exception data:
com.ibm.ejs.persistence.OptimisticUpdateFailureException: executeUpdate
returned zero rows updated
|
Cause
|
When starting a node, the scheduler thread for this node
will try to recover jobs which may have been processing but were not
complete when the node shut down. This occurs in a single server
environment, if the Java™ Virtual Machine (JVM) crashes while a scheduled
job is still running. When WebSphere Commerce begins to process a
scheduled job, it's state is set to 'Running' in the database. If the JVM
crashes while the job is running, the job will be left in this 'Running'
state. During startup, WebSphere Commerce detects any jobs that were left
running and attempts to recover them.
|
Diagnosing the
problem
|
The exception should happen on startup while trying to
recover the processed jobs. Look for the following methods, related to the
Scheduler recovering jobs, in the trace stack that is dumped when the
exception occurs.
at com.ibm.commerce.scheduler.Scheduler.recoverJob(Scheduler.java:1567)
at com.ibm.commerce.scheduler.Scheduler.init(Scheduler.java:1331)
at
com.ibm.commerce.scheduler.SchedulerComm.init(SchedulerComm.java:121)
|
Resolving the
problem
|
No action is required. This is the expected behavior, and
this exception can be ignored in this scenario.
Additional information
In the case of a clustered environment, there is a scheduler on each
node, and at any time, the scheduler on any node can be running. When a
node is starting, it looks to see if any jobs in Running state need to be
recovered. In a cluster, a job left in Running state may be detected as
needing recovery, while it is being processed by another node.
In this case, the scenario will be detected as an
OptimisticUpdateFailureException, and the job will only be processed on
one server. This exception can be ignored in this scenario, as it was the
expected behavior when trying to recover a job which is being run by a
second application server.
|
|
|
Cross Reference information
|
Segment
| Product
| Component
| Platform
| Version
| Edition
|
Commerce
| WebSphere Commerce - Express
| General
| i5/OS, Linux, Windows
| 6.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.0.0.4
|
|
Commerce
| WebSphere Commerce Professional Edition
| General
| AIX, i5/OS, Linux, Solaris, Windows
| 6.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.0.0.4
| Professional Edition
|
|
Current web document: http://www.ibm.com/support/docview.wss?uid=swg21273263
|