Technote

(troubleshooting)
SchedulerStatus bean throws com.ibm.ejs.persistence.OptimisticUpdateFailureException
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
   

Document Information

Current web document: http://www.ibm.com/support/docview.wss?uid=swg21273263