<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 9/19/13 9:49 AM, Scott Marlow wrote:<br>
    </div>
    <blockquote cite="mid:523B00F0.7020702@redhat.com" type="cite">On
      09/19/2013 05:13 AM, Stuart Douglas wrote:
      <br>
      <blockquote type="cite">
        <br>
        On Wed, Sep 18, 2013 at 2:54 PM, Scott Marlow
        &lt;<a class="moz-txt-link-abbreviated" href="mailto:smarlow@redhat.com">smarlow@redhat.com</a>
        <br>
        <a class="moz-txt-link-rfc2396E" href="mailto:smarlow@redhat.com">&lt;mailto:smarlow@redhat.com&gt;</a>&gt; wrote:
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; What are the requirements for supporting Batch section 11.6
        [1]?&nbsp; From
        <br>
        &nbsp;&nbsp;&nbsp; looking at JSR352, I get that each "chunk" has its own JTA
        transaction.
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I previously had heard that we only supported starting
        the
        <br>
        &nbsp;&nbsp;&nbsp; transaction
        <br>
        &nbsp;&nbsp;&nbsp; from the application processing code (via UserTransaction)
        but I think
        <br>
        &nbsp;&nbsp;&nbsp; the Batch container/runtime should start a JTA transaction
        for each
        <br>
        &nbsp;&nbsp;&nbsp; "chunk" that is processed.&nbsp; What are we really doing for
        managing the
        <br>
        &nbsp;&nbsp;&nbsp; JTA transactions for batch?
        <br>
        <br>
        <br>
        The spec says:
        <br>
        <br>
        8.2.1 Each chunk is processed in a separate transaction. See
        section 9.7
        <br>
        for more
        <br>
        details on transactionality.
        <br>
        <br>
        To me that implies the batch implementation starts the
        transaction
        <br>
        itself, although it does seem very vague. For instance looking
        at those
        <br>
        diagrams it looks like the transaction is committed even if an
        exception
        <br>
        is thrown, and it also does not seem to give you any possibility
        of
        <br>
        managing the transaction yourself, or doing non-transactional
        work.
        <br>
      </blockquote>
      <br>
      It looks like our batch implementation [4] is starting the
      transaction (via UserTransaction), however, we do rollback the
      transaction (see line 284) if an exception is thrown.&nbsp; I'm not
      clear on what happens to the transaction for the different
      exception handling cases talked about in "8.2.1.4.2 Retrying
      Exceptions".&nbsp; Cheng?
      <br>
    </blockquote>
    For a retryable exception, its transaction behavior is further
    specified in 8.2.1.4.4 Default Retry Behavior - Rollback.&nbsp; Basically
    it says the transaction will be rolled back before retry, but it can
    be configured not to rollback.&nbsp; You can also configure a retry limit
    for the chunk.<br>
    <br>
    <blockquote>8.2.1.4.4 Default Retry Behavior - Rollback<br>
      When a retryable exception occurs, the default behavior is for the
      batch runtime to rollback the current chunk and re-process it with
      an item-count of 1 and a checkpoint policy of item. If the
      optional ChunkListener is configured on the step, the onError
      method is called before rollback. The default retry behavior can
      be overridden by configuring the no-rollback-exception-classes
      element. See section 8.2.1.4.5 for more information on specifying
      no-rollback exceptions.<br>
    </blockquote>
    Cheng<br>
    <blockquote cite="mid:523B00F0.7020702@redhat.com" type="cite">
      <br>
      For non-transactional work, batch has the concept of a batchlet
      which is described as:
      <br>
      <br>
      "
      <br>
      The batchlet element specifies a task-oriented batch step. It is
      specified as a child element of the step element. It is mutually
      exclusive with the chunk element.&nbsp; See 9.1.2 for further details
      about batchlets. Steps of this type are useful for performing a
      variety of tasks that are not item-oriented, such as executing a
      command or doing file transfer.
      <br>
      "
      <br>
      <br>
      Also, I gave a sample batch application [5] a spin yesterday and
      our JPA deployment code scanned the transaction scoped persistence
      context and did the right thing.
      <br>
      <br>
      [4]
<a class="moz-txt-link-freetext" href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/runtime/runner/ChunkRunner.java">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/runtime/runner/ChunkRunner.java</a><br>
      <br>
      [5]
<a class="moz-txt-link-freetext" href="https://github.com/arun-gupta/javaee7-samples/tree/master/batch/chunk-csv-database">https://github.com/arun-gupta/javaee7-samples/tree/master/batch/chunk-csv-database</a><br>
      <blockquote type="cite">
        <br>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; REGULAR CHUNK PROCESSING &amp; JPA
        <br>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; For the JPA support for regular chunk processing [1], the
        following will
        <br>
        &nbsp;&nbsp;&nbsp; give a new underlying persistence context per chunk (jta
        tx):
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; @PersistenceContext(unitName =
        "chunkNonpartitionedAZTT4443334")
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EntityManager em;
        <br>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; PARTITIONED CHUNK PROCESSING &amp; JPA
        <br>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; For the JPA support for partitioned chunk processing [2],
        the following
        <br>
        &nbsp;&nbsp;&nbsp; will give a new underlying persistence context per chunk
        (jta tx):
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; @PersistenceContext(unitName =
        "chunkpartitionedAZTT4443334")
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EntityManager em;
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; One concern that I have about partitioning is the
        performance impact of
        <br>
        &nbsp;&nbsp;&nbsp; deadlocking and waiting for the JTA transaction to time
        out.&nbsp; Depending
        <br>
        &nbsp;&nbsp;&nbsp; on whether the work is configured to retry or not, hitting
        several dead
        <br>
        &nbsp;&nbsp;&nbsp; locks in a batch process could defeat some of the
        performance gains of
        <br>
        &nbsp;&nbsp;&nbsp; partitioning.&nbsp; Avoiding deadlocks by always
        reading/writing/locking the
        <br>
        &nbsp;&nbsp;&nbsp; underlying database resources in the same exact order, would
        help avoid
        <br>
        &nbsp;&nbsp;&nbsp; deadlocks.
        <br>
        <br>
        <br>
        IMHO if you are attempting to partition work that results in a
        deadlock
        <br>
        then you are basically doing something wrong. Also, as each
        chunk should
        <br>
        be basically running the same code but with difference data, in
        general
        <br>
        it should acquire locks in the same order anyway.
        <br>
      </blockquote>
      <br>
      Hard to say since this is user code that is being invoked (all
      kinds of ordering issues could easily be introduced via several
      layers of conditional code).&nbsp; There could also be unexpected use
      of the same application database while the batch process is
      running.&nbsp; The application code could also access the database rows
      in a different order as well (or pages if using page level
      locking).
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Stuart
        <br>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; Beyond the basic JPA capability of ensuring that each
        "chunk", has its
        <br>
        &nbsp;&nbsp;&nbsp; own persistence context, how else can we help the batch
        processing
        <br>
        &nbsp;&nbsp;&nbsp; experts writing JSR-352 applications on WildFly/Hibernate?
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; Anything else to discuss about JPA &amp; Batch?
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; [1] Batch spec section section 11.6 Regular Chunk Processing
        <br>
        &nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="https://gist.github.com/scottmarlow/6603746">https://gist.github.com/scottmarlow/6603746</a>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; [2] Batch spec section Batch 11.7 Partitioned Chunk
        Processing
        <br>
        &nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="https://gist.github.com/scottmarlow/6607667">https://gist.github.com/scottmarlow/6607667</a>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; [3] persistence.xml
        <a class="moz-txt-link-freetext" href="https://gist.github.com/scottmarlow/6608533">https://gist.github.com/scottmarlow/6608533</a>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp; _______________________________________________
        <br>
        &nbsp;&nbsp;&nbsp; wildfly-dev mailing list
        <br>
        &nbsp;&nbsp;&nbsp; <a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
        <a class="moz-txt-link-rfc2396E" href="mailto:wildfly-dev@lists.jboss.org">&lt;mailto:wildfly-dev@lists.jboss.org&gt;</a>
        <br>
        &nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>