PM68607: SKIPLISTENER ONLY GETS CALLED ONCE FOR EVERY BATCH INTERVAL UPDATE.

8.0.0.3: WebSphere Extended Deployment Compute Grid V8.0 Fix Pack 3
8.0.0.4: WebSphere Extended Deployment Compute Grid V8.0 Fix Pack 4
8.0.0.5: WebSphere Extended Deployment Compute Grid V8.0 Fix Pack 5

APAR status

• Closed as program error.

Error description

• Customer is using WebSphere Compute Grid  V8.0.0.1. It appears
  that the SkipListener is called once for every batch_interval
  update and if they have multiple exceptions in that
  batch_interval all are not getting caught.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of WebSphere Extended Deployment  *
  *                  Compute Grid.                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: Skip-record exception processing with   *
  *                      BDS JDBCWriters will                    *
  *                      only call listener once and increment   *
  *                      count once per SQL batch.               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Note throughout that the term "batch" here generally refers to
  standard JDBC batch updates, not to the "batch"-style
  processing with programming model provided by the Compute Grid
  product.
  The fundamental issue here is a suboptimal fit between the
  skip-record processing and the batch SQL execution performed by
  the LocalJDBCWriter/JDBCWriter BDS writers.  The skip-record
  processing is generally designed to count the number of skipped
  records against a user-configured limit and to call a
  user-supplied skip listener passing the skipped (possibly bad)
  record. The SQL batch execution used by these writers batches a
  sequence of SQL statements and executes them all at once
  against
  the database.   The problem is a mismatch in granularity then
  between the per-record exception the skip-record processing
  expects and the per-batch exception (in the form of a
  BatchUpdateException) that the batch execution will throw.
  In other words, if a BatchUpdateException is thrown we were
  treating it as a single failure without trying to figure out
  exactly which statements within the batch had succeeded or
  failed (and failed with which particular exceptions).   The
  main
  challenge here is that there is not a standard (JDBC-specified)
  mechanism for picking apart a BatchUpdateException returned by
  a particular JDBC driver in a particular configuration.
  

Problem conclusion

• The behavior with this fix depends on whether the user is using
  a JDBC driver configuration that performs an atomic or a
  non-atomic batch execution style.   Generally for the "atomic"
  style, the batch execution will abort on the first failure,
  whereas for "non-atomic" style, the rest of the batch will be
  executed.
  
  First, for a driver using atomic style, the runtime will abort
  the step execution loop, i.e. throw an exception rolling back
  the current transaction.
  
  For a driver using non-atomic style, the runtime will use a
  heuristic to try to pick apart the BatchUpdateException looking
  at the chained SQLException(s) . It will try to figure out
  which statements within the batch execution resulted in errors,
  and map that back to the corresponding record, calling the
  skip listener with the corresponding record and corresponding
  chained SQLException.   It will also increment the skip count
  once for each record resulting in exception within the batch,
  not just once for the entire batch.
  
  If this mapping cannot be made (for non-atomic style), and a
  skip listener has been configured, the runtime will call the
  skip listener once for each problem record, but passing the
  top-level BatchUpdateException.   But if the mapping cannot
  be made and a skip listener hasn't been configured, the
  runtime will abort the step execution loop by throwing an
  exception.
  

Temporary fix

• This fix is available
  via an iFix which is available upon request.
  

Comments

APAR Information

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

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

  PM71882

Fix information

• Fixed component name

  WXD COMPUTE GRI

• Fixed component ID

  5725C9301

Applicable component levels

• R800 PSY

     UP