Topic
  • 2 replies
  • Latest Post - ‏2012-05-24T05:30:20Z by SuhaasKrishna
SuhaasKrishna
SuhaasKrishna
5 Posts

Pinned topic EJB threw Transaction Time out Exception and other quires

‏2012-05-22T18:10:03Z |
Hi Sir

we are working for the project, i have faced the following challenges while developing WCG applications.Kindly help me in the following quires.we are using CG V8.
1.Two applications app1 and app2, are regular j2ee applications(not batch) which perform some business logic and end up with storing some results in data base called MyDB.

I have a batch application,single job consists of 3 job steps,first step is independent but step 2 is dependent on above mentioned app1 and app2 i.e step 2 should read data from MyDB after app1 and app2 work done. So batch application should wait for app1 and app2 to finish their work after executing step 1 of batch job.Once app1 and app2 finishes their works rest of the batch job should be completed normally.

I tried this scenario by calling Thread.sleep(time) method form createjobstep() method of step 2 to wait for MyDB ready to process. It is working fine.Is there any problem with this approach in real time.

Is compute Grid providing any cleaner way of dealing this scenario instead of using Thread.sleep().
2. There are two different jobs(two xjcls) submitted, both are executing in end point,i am trying to check jobstatus(using ejb interface) of first job in process method/create step method of some job step of second job.My intension is to suspend the second job until the first job ends. While doing this i am getting an error "ejb threw transaction time out exception in making call to getjobstatus method"

5/10/12 18:23:40:781 IST 00000049 EmbeddableTra I WTRN0041I: Transaction 000001369C5076310000000271410D400D49AC5C2F4B7ED606D3F6C230B4DCCC2A805AA6000001369C5076310000000271410D400D49AC5C2F4B7ED606D3F6C230B4DCCC2A805AA600000001 has been rolled back.

5/10/12 18:23:40:781 IST 00000049 RemoteExcepti E CNTR0019E: EJB threw an unexpected (non-declared) exception during invocation of method "getJobStatus". Exception data: com.ibm.websphere.csi.CSITransactionRolledbackException: Transaction rolled back; nested exception is:
javax.transaction.TransactionRolledbackException: Transaction is ended due to timeout

at com.ibm.ejs.csi.TransactionControlImpl.completeTxTimeout(TransactionControlImpl.java:1355)

at com.ibm.ejs.csi.TransactionControlImpl.preInvoke(TransactionControlImpl.java:283)

at com.ibm.ejs.container.EJSContainer.preInvokeActivate(EJSContainer.java:4023)

at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:3375)

at com.ibm.websphere.longrun.EJSRemoteStatelessJobScheduler_d7897126.getJobStatus(Unknown Source)

at com.ibm.websphere.longrun._JobScheduler_Stub.getJobStatus(_JobScheduler_Stub.java:1296)

at pack1.Test.checkJobStatus(Test.java:187)

at pack1.steps.JobDependencyCheck.method(JobDependencyCheck.java:169)

at pack1.steps.JobDependencyCheck.createJobStep(JobDependencyCheck.java:34)

at com.ibm.ws.gridcontainer.batch.impl.StepManagerImpl.setupStep(StepManagerImpl.java:283)

at com.ibm.ws.gridcontainer.security.actions.SetupStepBatchUserPrivilegedAction.executeAction(SetupStepBatchUserPrivilegedAction.java:45)

at com.ibm.ws.gridcontainer.security.AbstractUserPrivilegedAction.runWithoutSecurity(AbstractUserPrivilegedAction.java:66)

at com.ibm.ws.gridcontainer.services.impl.WASRunUnderCredentialServiceImpl.runUnderUserCredential(WASRunUnderCredentialServiceImpl.java:134)

at com.ibm.ws.gridcontainer.services.impl.WASRunUnderCredentialServiceImpl.runActionUnderUserCredential(WASRunUnderCredentialServiceImpl.java:367)

at com.ibm.ws.gridcontainer.batch.impl.JobManagerImpl._setupStep(JobManagerImpl.java:836)

at com.ibm.ws.gridcontainer.batch.impl.JobManagerImpl._sequentialStepScheduling(JobManagerImpl.java:738)

at com.ibm.ws.gridcontainer.batch.impl.JobManagerImpl.executeJob(JobManagerImpl.java:198)

at com.ibm.ws.batch.BatchJobControllerWork._runJob(BatchJobControllerWork.java:299)

at com.ibm.ws.batch.BatchJobControllerWork.run(BatchJobControllerWork.java:219)

at com.ibm.ws.asynchbeans.J2EEContext.run(J2EEContext.java:809)

at com.ibm.ws.asynchbeans.WorkWithExecutionContextImpl.go(WorkWithExecutionContextImpl.java:222)

at com.ibm.ws.asynchbeans.ABWorkItemImpl.run(ABWorkItemImpl.java:206)

at java.lang.Thread.run(Thread.java:769)

Caused by: javax.transaction.TransactionRolledbackException: Transaction is ended due to timeout

at com.ibm.tx.jta.impl.EmbeddableTranManagerImpl.completeTxTimeout(EmbeddableTranManagerImpl.java:62)

at com.ibm.tx.jta.impl.EmbeddableTranManagerSet.completeTxTimeout(EmbeddableTranManagerSet.java:85)

at com.ibm.ejs.csi.TransactionControlImpl.completeTxTimeout(TransactionControlImpl.java:1347)

... 22 more

What is the mistake i have done.how to get out of it?
3.Can we use PJM with batch jobs without Data streams.i,e zero input and out put streams? what is the difference in writing run property at job level and step level.Can i have multiple run properties at job level? could you
tell me how to write the following scenario

job has four steps step1 and step2 run parallel based one parameterizer and other two steps run parallel based on another parameterizer.

If only one parameterizer used, how to make step1 and step2 run in parallel(parallel sub job should contain two steps step1 and step2) and step3 and step4 run in parallel(parallel sub job should contain two steps step3 and step4).

Thanks in Advance

SuhaasKrishna
Updated on 2012-05-24T05:30:20Z at 2012-05-24T05:30:20Z by SuhaasKrishna
  • sajan
    sajan
    42 Posts

    Re: EJB threw Transaction Time out Exception and other quires

    ‏2012-05-22T20:27:27Z  
    For question 1 (Q1): It sounds like you want to process step 1, then wait for some external processing to complete (assuming step 1 triggers the external processing in app1 and app2), then process step 2 by consuming the data produced by the external process. Instead of adding the wait logic to the create method in the step 2, why not build that wait logic as a whole step which checks the db for data and if not ready waits for a defined interval and repeats this until data is ready. This way, you do not have to configure a single long wait interval that accounts for all delays in the system including peak workload, etc. Instead, you wait for a shorter interval and if not ready wait again for a shorter interval and retry.

    For Q2: If job 2 cannot start processing until job 1 ends, why can't they be steps in a single job. If you already considered that option and ruled it out as not feasible for some reason, then did you also consider the following options
    (a) final step in Job 1 submitting Job 2
    (b) Job 1 and Job 2 in Compute Grid are actually steps of a Job managed by an external scheduler
    (c) if you have to process these two jobs like you are doing now, you should at least consider taking the monitor step out of global transaction (local transaction or no transaction like a CI step) or allow taking checkpoints between repeated monitor-wait actions.

    For Q3: There are multiple questions here:
    (a) 'can use PJM without data streams?' - Yes, you can. A compute-intensive step is a step without BDS and could be part of a PJM job. Our IVT/Mailer sample demonstrates this.
    (b) difference between 'run property at job level and step level' - With the run element at the job level, the job as a whole is processed across multiple threads or JVMs i.e all the steps in that job will be processed across multiple threads/JVMs. With the step level run element, you can choose which steps in the job to be processed parallely and which are processed in a single thread fashion.
    (c) 'can I have multiple run properties at the job level' - No, you cannot have multiple run elements at the job level.
    (d) could you clarify what you mean by 'step1 and step2 run parallel based one parameterizer' and 'other two steps run parallel based on another parameterizer.'? Typically parameterizer provides parameters for parallel step/job which execute the same business logic across multiple threads/JVMs with different parameters. If so, do step 1 and step 2 referred here are just two threads executing the same business logic but with different data?

    Sajan.
  • SuhaasKrishna
    SuhaasKrishna
    5 Posts

    Re: EJB threw Transaction Time out Exception and other quires

    ‏2012-05-24T05:30:20Z  
    • sajan
    • ‏2012-05-22T20:27:27Z
    For question 1 (Q1): It sounds like you want to process step 1, then wait for some external processing to complete (assuming step 1 triggers the external processing in app1 and app2), then process step 2 by consuming the data produced by the external process. Instead of adding the wait logic to the create method in the step 2, why not build that wait logic as a whole step which checks the db for data and if not ready waits for a defined interval and repeats this until data is ready. This way, you do not have to configure a single long wait interval that accounts for all delays in the system including peak workload, etc. Instead, you wait for a shorter interval and if not ready wait again for a shorter interval and retry.

    For Q2: If job 2 cannot start processing until job 1 ends, why can't they be steps in a single job. If you already considered that option and ruled it out as not feasible for some reason, then did you also consider the following options
    (a) final step in Job 1 submitting Job 2
    (b) Job 1 and Job 2 in Compute Grid are actually steps of a Job managed by an external scheduler
    (c) if you have to process these two jobs like you are doing now, you should at least consider taking the monitor step out of global transaction (local transaction or no transaction like a CI step) or allow taking checkpoints between repeated monitor-wait actions.

    For Q3: There are multiple questions here:
    (a) 'can use PJM without data streams?' - Yes, you can. A compute-intensive step is a step without BDS and could be part of a PJM job. Our IVT/Mailer sample demonstrates this.
    (b) difference between 'run property at job level and step level' - With the run element at the job level, the job as a whole is processed across multiple threads or JVMs i.e all the steps in that job will be processed across multiple threads/JVMs. With the step level run element, you can choose which steps in the job to be processed parallely and which are processed in a single thread fashion.
    (c) 'can I have multiple run properties at the job level' - No, you cannot have multiple run elements at the job level.
    (d) could you clarify what you mean by 'step1 and step2 run parallel based one parameterizer' and 'other two steps run parallel based on another parameterizer.'? Typically parameterizer provides parameters for parallel step/job which execute the same business logic across multiple threads/JVMs with different parameters. If so, do step 1 and step 2 referred here are just two threads executing the same business logic but with different data?

    Sajan.
    Thanks sajan,great help,your solution really worked.I need more help in same quires.

    Actually I tried CI step for wait logic in both Q1 and Q2.I thought if some thing go wrong in CI step of job(Job is Mix of batch and CI steps) this will not go in restartable state since CI job has no restartable state.
    If I use batch step for wait logic,if any thing go wrong in it,it will go in restartable state thats fine we can restart it.
    1.Is my assumtion is correct or not?
    2.what are all possible final states for both batch and ci jobs?
    3.If i use mix type job,can it be ended in restartable state?
    Thanks once again,

    SuhaasKrishna