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

8.5.0.2: WebSphere Application Server V8.5 Fix Pack 2

APAR status

• Closed as program error.

Error description

• When using skip-record processing with the LocalJDBCWriter and
  JDBCWriter batch data stream framework (BDS) writers,
  the skip listener will only be called once and the count only
  incremented once, for an entire SQL batch execution.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  Users of the batch function of IBM          *
  *                  WebSphere Application Server V8.5.          *
  ****************************************************************
  * PROBLEM DESCRIPTION: Skip-record exception processing with   *
  *                      BDS JDBCWriter(s) only calls listener   *
  *                      once and increments skip 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 batch function
  within WebSphere Application Server.
  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 runs 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.
  
  The fix for this APAR is currently targeted for inclusion in
  fix packs 8.5.0.2.  Please refer to the Recommended Updates
  page for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

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

Comments

APAR Information

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

  PM68607

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

Fix information

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R850 PSY

     UP