Chapter 4 configure and run a task (below)-spring batch

Document directory

• 4.4.1 start a task from the command line
• 4.4.2 run tasks through web containers
• 4.5.1. query memory
• 4.5.2. Task register
• 4.5.4. jobparametersincrementer)
• 4.5.5. Stop a task
• 4.5.6. Cancel the task

(Declaration: the translation has not been verified. Do not reprint it)

4.3 configure a "task initiator"

The simplest implementation of the "jobluncher" interface is "simplejobluncher ". It only depends on one "job memory (jobrepository)", so that it has the ability to execute tasks:

As long as you have a "job executor", it will call the "job" execution method and finally return the "job executor" to the caller:

When starting from a scheduler, the execution sequence is straight and works well. However, if you start from a website request, the problem arises. In this scenario, the running process must be asynchronous so that "simplejobluncher" can immediately return a result to the caller. This is because a website request is suspended for a long time and it is certainly not feasible to run a batch task. As shown in the sequence diagram:

By configuring a "taskexecutor", simplejobluncher can be applied to this scenario:

The implementation of any "subtask executor" interface can be used to control asynchronous execution of tasks.

4.4. Run a task.

When running a task, two things are essential: the "job" to be run and a "job initiator (jobluncher )". They can either be placed in the same context or in different contexts. For example, when a task is started from a command, a new Java Virtual Machine (JVM) will be instantiated to serve each task. As a result, each task has its own "job initiator )". However, if a Web Container uses "httprequest", there is usually only one "job initiator (jobluncher)" and it is configured as an asynchronous startup mode, in this way, multiple requests can be in parallel.

4.4.1 start a task from the command line

Command lines are preferred for users who want to run tasks from an enterprise-level scheduler. This is because most schedulers (where quartz is an exception and nativejob is used) run directly in the form of operating system processes and generally start through system scripts. In addition, there are many ways to start a JAVA process, such as Perl, Ruby, or even "build tools" such as ant or Maven )". But because most people are used to scripts, this example will focus on this.

4.4.1.1. commandlinejobrunner)

Because the script must start a task through the Java virtual machine, a class containing the "Main" method is required as the entry of the program. Spring batch provides an implementation that meets this requirement: "commandlinejobrunner )". You must note that this is only one way to start a task. In addition, there are many other ways to start a Java Process. Do not think this is the only way. The "commandlinejobluncher" Operation takes four steps:

Load appropriate application context explanation the command line parameter is "Job parameters (jobparameter). Based on parameters, locate appropriate tasks. Use" Job initiator (jobluncher) "to provide the application context required to start the job.

All these steps will only be executed based on the input parameters until they are completed. The following is a list of required parameters:

These parameters must be passed in the order of "path" first and "name. All subsequent parameters are considered as "task Parameters", and the format must be "name = value ":

Most of the time, you need to display the class that declares the main method you packaged in the jar file, but you can simply use it for simplicity. The example uses the same "endofday" in the same domain ". The first parameter is "endofdayjob. xml", indicating the Spring "application context (applicationcontext)" containing the task )". The second parameter "endofday" indicates the task name. For the final parameter, "schedule. date (date) = 2007/05/05" will be converted to "job parameters )". The xml configuration example is as follows:

This example is too simple, because it is usually necessary to start a task in spring batch, but it is used to represent two "command line starters (commandlinejobrunner) "The two basic configurations are good:" job "and" jobluncher )".

4.4.1.2. Exit code

Generally, an enterprise-level scheduler is always used when a batch task is started through a command line. Most schedulers are executed in the background and only at the process level. This means that they only know information about operating system processes, such as the shell scripts they call. In this scenario, the system informs the backend scheduler whether a task is successful or failed, and only the return code after the task is executed. The return code refers to the result code that the executed process returns to the scheduler at the end. In the simplest case, 0 indicates success, and 1 indicates failure. However, the general scenario is much more complicated than this: If task a returns 4, Task B starts, and task C starts if task a returns 5. This type of behavior can be configured at the scheduler level, but it is important that the currently used framework, such as spring batch, it is necessary to provide a variety of exit codes for a special task )". The exit code in spring batch is encapsulated as "exitstatus", which will be discussed in chapter 5. Since we are discussing the exit code, we only need to remember one important thing, that is, an "Exit status (exitstatus)" has a framework (or developer) the exit code attribute is returned to the job initiator as part of the jobexecution process )". The "commandlinejobrunner" interface is used to "exit the code Er (exitcodemapper)" to convert the string value to an integer:

The basic "Exit code Er (exitcodemapper)" contract is like this. Given a string exit code, the corresponding integer is returned. After the task is executed, the default exit code ER interface is implemented as "simplejvmexitcodemapper". When the task is completed, 0 is returned, and 1 is returned, indicating a general error, 2 indicates a task startup error. For example, the specified task cannot be found in the provided context. If you need more complex return codes for three additional results, you need to provide a custom "Exit code Er ". Because the "command line task initiator" creates an application context, to prevent "wrapped together", any value to be overwritten needs to be automatically assembled. This means that if the custom implementation of an exit code er is found by the beanfactory, it will be automatically injected into the initiator after the context is created. The only thing that needs to be done is to declare your custom exit code er as the implementation of the root-level bean interface, and ensure that in the application context loaded by the initiator, it is a part of it.

4.4.2 run tasks through web containers

Generally, offline batch task processing is started through the command line, as discussed above. However, in many cases, it is better to start a task through "httprequest. Many such cases, such as reports, ad-hoc task execution, and Web application support. Because the batch task is defined as a long process, the most important thing is to make sure that the task is started asynchronously:

The Controller in the figure is spring MVC controller. For more information about spring MVC, see http://static.springframework.org/spring/docs/2.5.x/reference/mvc.html. Through the configured "job initiator", the controller can start a job asynchronously and immediately return a "job execution process (jobexecution )". Although the task is still being executed, non-blocking mode allows the Controller to return immediately, which is crucial for processing "page requests. For example:

4.5. Advanced metadata usage

So far, we have discussed the "jobluncher" and "jobrepository" interfaces. Together, they implement how to start a task and perform basic "crud" operations on batch domain objects:

Jobluncher uses jobrepository to create and run a new jobexecution. During task execution, the implementation instance of "job" and "Step" will use the same "job memory (jobrepository)" later) "For simple update operations. These basic operations can only meet the requirements of simple scenarios. In a large batch task environment with hundreds of tasks and complex process requirements, you need to further access metadata:

Next, we will discuss the "job Explorer" and "job operator" interfaces, which will satisfy the query and control of metadata to a certain extent.

4.5.1. query memory

Before using any advanced features, the most basic requirement is to be able to query the existing executors in the current memory. The job explorer interface provides the following methods:

As shown in the signature above, "job Explorer" is a read-only version of "job memory (jobrepository)", just like the latter, it can be generated through simple configuration of factory beans:

In the earlier part of this chapter, we mentioned that the table prefix of "job memory (jobrepository)" can be changed to support different versions or architectures. Because "job Explorer" uses the same table, it is extremely important to configure the table prefix:

4.5.2. Task register

The so-called "jobregistry" is not mandatory (its parent interface is "job locator joblocator "), however, if you want to track which tasks are effective in the current context, it is useful. It is also useful for collecting tasks created elsewhere in an application context (for example, in a lower-level context ). The custom implementation of jobregistry can also be used to change the task name or other registered attributes. The framework only provides one implementation, based on a simple ing table (MAP): name, and the corresponding task instance. You can configure it as follows:

There are two methods to automatically form the jobregistry: Use the bean sending processor and use the register lifecycle management container ". The following two methods are discussed.

4.5.2.1. jobregistrybeanpostprocessor)

This is a bean sending processor that can be used to register all created tasks:

Although it is not necessary to assign an ID to the "sending processor" in the example, it can be specified in the lower-level context (defined as the upper-level bean itself ), you can automatically register all created tasks.

4.5.2.2 automatic task register

This is a lifecycle management container used to create subordinate contexts and register all tasks created in these contexts. The advantage of this is that their dependencies can have a "natural" name, but they must still be globally unique in the current Registrar. For example, you can create a large number of xml configuration files, each of which contains only one task, but different "element readers (itemreader)" are defined using the same name )", for example, "Reader ". If these configuration files are introduced into the same context, the reader definition will conflict with other definitions with the same name, but this will not happen if the reader is automatically registered. This makes it easier to integrate each separated application module to a task.

The register contains two managed properties: applicationcontextfactory (which will be created from the appropriate factory bean) and jobloader )". The task loader manages the lifecycles of lower-level contexts and registers tasks to the task memory.

Applicationcontextfactory is responsible for creating subordinate contexts. The most common usage is the classpathxmlapplicationcontextfactory shown above. One feature of this factory class is to copy several configurations in the context of the previous level to the next level by default. In this case, if the propertyplaceholderconfigurer or AOP configuration defined in the next-level context is the same as that defined in the previous-level context, the definition does not need to be repeated.

If strongly required, automaticjobregistrar can be used together with jobregistrybeanpostprocessor (just like defajojobloader ). For example, a task defined in the upper-level main context must also be used at the lower-level.

4.5.3 job operation class (joboperator)

As mentioned above, "job memory (jobrepository)" provides "add, query, modify" operations for metadata, while "job Explorer" provides several read-only operations. By using multiple batch operations, you can complete a considerable number of task control functions, such as stopping, restarting, or summarizing tasks. Spring batch defines interfaces like joboperator and provides the following functions:

The operations shown in the preceding figure reproduce many functions provided by other interfaces, such as "joblucher", "jobrepository", and "jobexplorer )", there is also the jobregistry )". For this reason, the simplejoboperator Implementation of the "job operation interface (joboperator)" has many dependencies:

Note:

If you set the table prefix in the task memory, do not forget to make the same settings in the task browser.

4.5.4. jobparametersincrementer)

Most joboperator methods are self-explanatory. You can get more detailed descriptions through javadoc of the interface. However, the method "startnextinstance" is useless. This method provides a new instance of the task. If there are several "job execution processes (jobexecution)" and the job needs to be restarted from the beginning, this method is quite useful at this time. Unlike jobluncher, starting a new task requires a new parameter instance. If the parameters are different, startnextinstance binds the current jobparametersincrementer to this task and forces it to generate a new instance:

The Protocol for "task parameter incrementally" is as follows. When a "task parameter" object is specified, it returns the "Next" task parameter "object, at the same time, fill in any value that may be needed. This policy is useful because the framework does not need to know what changes it has made to change to the "Next" task parameter instance. For example, if the task parameter contains only one date parameter, should this value be auto-incremented for one day when the next instance is created? Or one week (if the task runs in the surrounding unit )? This issue is involved in any task that contains numeric parameters if you need to differentiate them, as shown below:

In this example, the key value "Run. ID" is used to differentiate task instances. If the current task parameter is null, it is considered that the task has never been run, initialized for it at the same time, and then returned. Otherwise, if it is not null, a value is added and then returned. The auto-increment value can be set through the "incrementer" attribute of the task:

4.5.5. Stop a task

The most common function of "job operator" is to stop a job:

Closing does not happen immediately, because it is impossible to stop a task immediately, especially when the task is executed to the developer's own code segment, the framework is powerless at the moment, for example, a business logic processing. Once the control is returned to the framework, it immediately sets the current "execution step (stepexecution)" to "bachstatus. stopped, meaning to stop, save, and finally perform the same operation on the job executor before completion.

4.5.6. Cancel the task

When a task fails to be executed, if it can be restarted, it will be restarted. If the execution status of a task is "canceled", the framework will not restart it. The "cancel" status also applies to the execution steps so that they can be skipped, even in the execution of a restart task: if the task encountered a step marked as "canceled" after the previous failed execution, skip this step and go directly to the next step (this is determined by the exit code of the task flow definition and execution step ).

If the current system process is killed ("Kill-9" or a system error), the task is not running, but the "job memory" cannot detect this error, because no one has notified the process before it dies. You must manually tell it that you know the task has failed or want to discard it (set it to a failed or aborted state)-This is a business logic layer thing, automatic decisions cannot be made. You must set the task to failed only when the task cannot be restarted, or you know that the data is valid after the restart. Spring batch Admin has a series of tools, jobservice, to cancel ongoing tasks.