PH13367: WITH JAVA BATCH APPLICATIONS IN LIBERTY, JOB PARTITIONS FAIL DUE TO A DEADLOCK IN THE JOB REPOSITORY

19.0.0.10: WebSphere Application Server Liberty 19.0.0.10
19.0.0.11: WebSphere Application Server Liberty 19.0.0.11
19.0.0.12: WebSphere Application Server Liberty 19.0.0.12
20.0.0.1: WebSphere Application Server Liberty 20.0.0.1
20.0.0.2: WebSphere Application Server Liberty 20.0.0.2
20.0.0.3: WebSphere Application Server Liberty 20.0.0.3
20.0.0.4: WebSphere Application Server Liberty 20.0.0.4
20.0.0.5: WebSphere Application Server Liberty 20.0.0.5

APAR status

• Closed as program error.

Error description

• When running JSR 352 Java Batch applications in Liberty that
  have jobs with partitioned job steps, two of the job
  partitions
  fail due to a deadlock in the job repository.
  

Local fix

• n/a
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server Liberty- Batch                       *
  ****************************************************************
  * PROBLEM DESCRIPTION: Job Partitions reported failing due to  *
  *                      a deadlock on Java Batch Job Repository *
  *                      tables                                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Job partitions failed due to a deadlock in the job repository.
  The batch runtime datasource is on MSSQL.
  
  When using batch runtime's API getRunningExecutions, a deadlock
  was seen during the query (SELECT t0.JOBEXECID FROM
  dbo.WLPJOBEXECUTION t0, dbo.WLPJOBINSTANCE t1 WHERE
  (((t1.JOBNAME = @p0) AND (t0.BATCHSTATUS IN (@p1,@p2,@p3))) AND
  (t1.JOBINSTANCEID = t0.FK_JOBINSTANCEID)) ORDER BY t0.CREATETIME
  DESC)
  
  A deadlock was also seen performing a batch runtime operation
  updateJobExecutionAndInstanceOnStopBeforeServerAssigned which
  performs the update:
  (UPDATE dbo.WLPJOBEXECUTION SET BATCHSTATUS = @p0, ENDTIME =
  @p1, EXITSTATUS = @p2, UPDATETIME = @p3 WHERE (JOBEXECID =
  @P4)).  This is called when a stop of a job execution is
  performed, and the execution has not yet reached an endpoint.
  

Problem conclusion

• This problem is resolved in Open Liberty by
  https://github.com/OpenLiberty/open-liberty/issues/8532.
  
  A code update has been made to re-order the operations perfomed
  during the runtime calls mentioned in the Problem Summary.  The
  re-ordered operations are now performed in separate
  transactions, as it was not essential that they be tied
  together.
  
  The fix for this APAR is currently targeted for inclusion in fix
  pack 19.0.0.10.  Please refer to the Recommended Updates page
  for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  LIBERTY PROFILE

• Fixed component ID

  5724J0814

Applicable component levels

• R855 PSY

     UP