Announcement Announcement Module
Collapse
No announcement yet.
ExecutionContext is not being saved when job is stopped. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • ExecutionContext is not being saved when job is stopped.

    I have decider which may stop the job. i am putting different kind of objects into ExecutionContext object and it's is being saved correctly.
    But sometimes decider may decide o stop the job and i have this
    Code:
    <batch:end on="stop"/>
    to stop the job. But before stopping i am putting some information into ExecutionContext and returning stop sign. But this information is not being saved into db. other messages(I have put along the way before reaching decider) are being saved.

    Is that correct behavior or bug or my mistake?
    if it is correct behavior then any easy way to come around(to save ExecutionContext even before stopping)?

    Thanks.

  • #2
    Where are you getting an ExecutionContext from within your JobExecutionDecider?

    Comment


    • #3
      Hi.
      i am getting it from
      Code:
       public FlowExecutionStatus decide(JobExecution jobExecution, StepExecution stepExecution) {
              jobName = jobExecution.getJobInstance().getJobName();
              this.jobExecution = jobExecution;
              this.stepExecution = stepExecution;
      
              stepExecution.getJobExecution().getExecutionContext();
          }

      Comment


      • #4
        After the execution of a JobExecutionDecider, we don't persist the ExecutionContext since there isn't any state that would typically need to be recreated from it. I'd have to double check but we may need to add this to support JSR-352 (SB treats a decision as a special type of state, where the JSR treats it the same as any other step).

        What types of information are you storing from the decider itself? I'm wondering if you are overloading what it should be doing.

        Comment


        • #5
          Originally posted by mminella View Post
          After the execution of a JobExecutionDecider, we don't persist the ExecutionContext since there isn't any state that would typically need to be recreated from it. I'd have to double check but we may need to add this to support JSR-352 (SB treats a decision as a special type of state, where the JSR treats it the same as any other step).

          What types of information are you storing from the decider itself? I'm wondering if you are overloading what it should be doing.
          Hi that is a good question.
          I need to save some message about why it is stopped. I also log to a file, but We need persistence message in db.
          So I have created Simple message class and create instance of the class and save it at some important places. I see all messages are being serialized with xstream, I am fine with this. For each job there are maybe around ~20 messages.
          What do you think? Is that good approach using context for saving messages?

          Thanks.

          Comment


          • #6
            No Answers?
            Last edited by elbek; Apr 11th, 2013, 10:20 AM.

            Comment


            • #7
              ~~~~thanks.

              Comment


              • #8
                Why are you putting the message in the ExecutionContext? To access this, you'd have to deserialize the EC. Seems pretty painful to me. Plus it ties that data directly to Spring Batch. I'd just use the JdbcTemplate and store the values into their own log table.

                Comment


                • #9
                  Well. one job may have 15, 20 messages and they are tied to batch job. without batch framework they do not make sense.
                  I do not do any search on that table, All I do is when admin asks messages for particular job I go there and pull context and deserialize it and show messages. This is the only use case we may have.

                  Comment


                  • #10
                    I would still just use the JdbcTemplate and store the messages in a separate table. Then you wouldn't have to deserialize the context at all to show the messages.

                    Comment

                    Working...
                    X