Announcement Announcement Module
No announcement yet.
ExecutionContext saved when Step failed Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • ExecutionContext saved when Step failed


    I'm not clear about if the data stored in a step should be persisted to the database if a step fails.

    Now we use a FlatFileItemWriter that updates the items written and filesize into the ExecutionContext. We also have the FlatFileItemWriter working with a TransactionAwareBufferedWriter.

    We read from a JMS queue and write to a file and update a database.
    On error we see the transaction rolledback, so nothing get updated (including the file) exactly what we want. When we want to restart the job we have a problem however because the filesize and items written in the step execution is updated.

    A restart will now fail because the actual filesize is smaller than the filesize stored in the Steps Execution context.

    I would expect the attributes stored in the Execution context would not be stored in case of failure if we want to restart the job.


  • #2
    If you don't implement the ItemStream interface there are no guarantees if you write to a live execution context. Did you implement ItemStream for your writes to the context?


    • #3
      The org.springframework.batch.item.file.FlatFileItemWr iter is doing the update of the ExecutionContext (as that a subclass of ItemStream).


      • #4
        Then it should not be savng any state related to records that were rolled back. What version of Spring Batch are you using?


        • #5
          We're using 2.1.0.

          It seems to work if there is an Exception during the reads from JMS or during processing or writing to the database.

          It goes wrong when an exception occurs after the update is called.
          This could happen for example when a connection to JMS or the database is lost, or commit returns with an error.


          • #6
            Which transaction manager are you using?

            I would upgrade to 2.1.3 if I were you anyway.


            • #7
              org.springframework.transaction.jta.JtaTransaction Manager

              We'll do a test with 2.1.3 also to see if that solves the problem.


              • #8
                Even if exceptions happen after the repository is updated I would hope that the transaction manager can roll those changes back. Maybe there is a problem with Bitronix (I have heard of other issues with that TM caused by slightly odd choices of XA status messages).

                I might need to know a bit more about your use case and how exactly it is failing. What and where are the exceptions that are causing the rollbacks? Does it work with DataSourceTransactionManager and TransactionAwareConnectionFactoryProxy?


                • #9
                  Seems that BATCH-1572 is exactly the same problem as ours.
                  We have moved to 2.1.4 and the problem is solved.