You might encounter business grid behavior that is unexpected. This topic describes some common things to look for when business grid is not working as expected.
Failed to set up the WebSphere variables for the JDBC paths of the database used.
Having the same but incomplete WebSphere Application Server variables defined at the node level, causing the variables at the cell level to be overridden.
If the xJCL for a job specifies an incorrect application name, the long-running scheduler logs an IllegalStateException. The exception is harmless and the long-running scheduler continues to function correctly. The job state immediately changes to execution failed.
The processJobStep() or destroyJobStep() might go to an enterprise bean instance other than the instance under which the batch job step was originally dispatched, when setProperties() or createJobStep() was invoked. As a result, the processJobStep() or destroyJobStep() might run on a thread other than the thread under which it was previously dispatched. The reason is that an incorrect bean caching load policy was specified.
To correct this problem, modify the ibm-ejb-jar-ext.xmi file of the enterprise bean's module deployment descriptor to specify the activateAt and LoadAt variables. The step enterprise beans must have a caching policy of activating once and loading at activation, which is found in the ibm-ejb-jar-ext.xmi file of the enterprise beans module. The following is an example of a modified ibm-ejb-jar-ext.xmi file:
<enterpriseBean xmi:type="ejb:ContainerManagedEntity" href="META INF/ejb.jar.xml#PostingAccountData"/> <beanCache xmi:id="BeanCache_1131923814135" activateAt="ONCE" loadAt="ACTIVATION">
Changing this file ensures that in a given enterprise bean container, there will be at most one instance of a step enterprise bean with a given job ID in the cache, which ensures that every call that the long-running execution environment makes to processJobStep() for a given step will go to the same instance of the step enterprise bean. This is essential because global variables in the step enterprise bean (such as BDS references) are referenced across multiple processJobStep() calls.