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

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

In the previous chapter, we discussed the overall architecture design, such as solution for reference:

The "job" in looks like a "step (Steps)" container. There are quite a few configuration options that developers need to pay attention. At the same time, there are still many details about how to make a "task" Run and how its metadata is stored at runtime. This section will explain a large number of configuration options and a concern for running a task.

4.1 configure a task

There are two implementation methods for the "task" interface. However, through abstraction, they are consistent in configuration. Only three dependencies are required: one name, "task repository", and several "Steps ".

 

The above example uses a parent class "Bean" definition to create those "Steps". In the step configuration area, you can see more options, detailed information about the specific steps is stated in one line. The XML field is mapped to the storage repository with the ID "jobrepository" by default, which is easy to understand. But you can also reload it:

Under specific circumstances, the task step configuration can contain other elements to help with splitting (<split/>) and Process Policy Control (<demo-/>) and process extension (<flow/> ).

4.1.1 restart capability

When a batch task is executed, it is important to note when it will be restarted. When the specified "task instance" already has a "task execution instance", running this "task" is considered as "restart ". Theoretically, all tasks should be able to be started. If they are not running, they may not work in many scenarios. In this scenario, developers can only create a new "task instance ". This is not necessary in spring batch. If a "task" cannot be restarted but is always started as a part of the "task instance", set the attribute "restartable" to "false:

In other words, setting this attribute to false means "this task cannot be started again ". Restarting a "cannot be restarted again" task will cause "jobrestartexception ":

This JUnit code snippet shows the intention to create a "task execution process" for a "task" that cannot be restarted for the first time. Everything is fine, however, the exception we mentioned was thrown during the Second Creation.

4.1.2 interception of the task execution process

It is useful to add a number of events to third-party code During task execution. Simplejob allows you to listen to events as appropriate:

Through the listeners element, joblisteners can be added to simplejob:

Whether the task is successfully executed or not, it should be noted that afterjob will be called. To handle the difference, you can perform the following operations in the "task execution" class:

 

The preceding interface serves the following purpose:

4.1.3. inherit from parent task

If a group of tasks have similar but different configuration items, it is easier to define a "parent task" so that the "subtask" inherits its attributes. Similar to class inheritance in Java, subtasks accumulate the elements and attributes of their parent tasks.

In the following example, "basejob" is an abstract task that contains only several event listeners. The subtask "job1" is a specific task that inherits the event listener of the parent task and has its own defined event listener, so that the task has two sets of Event Listeners and one step, "Step 1 ":

4.1.4. Task parameter validator

You can declare a parameter validator for a running task by using the XML node attribute or inheriting from some abstract tasks. This is useful in task instances with required parameters. The following is an example of defaultjobparametersvalidator to verify the mandatory and optional parameter combinations. More complex verification algorithms can be implemented by yourself through interface inheritance. In the xml configuration file, you can add the validator configuration item subnode to the child node of the job, and so on:

The validators can be treated as a reference, or as an internal bean within the beans domain.

4.2 configure the task Repository

As discussed earlier, the "task repository" is used to perform basic "crud" operations on various entities using spring batch, for example, "task execution class" and "step execution class ". This is widely used in the main framework, such as the "task startup class", "task class", and "Step class. The framework abstracts the implementation details and associations of many "task repositories. Even so, some configuration options are useful:

Except ID, other options are optional. If no value is set, the default value is optional. To remind readers of its existence. The default value of "Max-varchar-length" is 2500. this parameter is used to set all columns of the "varchar" type, in the sample architecture script, fields such as the exit type code description are stored. If you do not modify the architecture and do not use dubyte, you do not need to change it.

4.2.1. Transaction configuration of the task Repository

If the specified attribute is used, the transaction function is automatically added to the repository. This is used to confirm the batch metadata, including the status required for restart after an error, and will be correctly persisted. The behavior of the Framework is elegant only when the methods of the repository are transactional. Among the many method attributes used to create (create *), the isolation level is defined as "specified separately" to determine when the task is started, if two processes attempt to start the same task at the same time, only one process can succeed. The default isolation level for that method is "serializable", which is highly risky: "read commit (read_committed)" will work normally; "Read uncommitted (read_uncommitted)" performs well only when two processes do not conflict. However, given that calling a created method is very short, it seems that "serialization" will not cause any trouble as long as the database platform can support it. Then there is a problem:

Even if the attribute or factory beans are not used, the transaction behavior of configuring the repository using AOP is also very basic:

This code segment can be referenced intact. Remember that colleagues who are using the corresponding attribute declaration should not forget to reference spring-TX and spring-AOP (or the entire spring) packages.

4.2.2. Change the table prefix

Another attribute that can be changed by jobrepository is the prefix of the metadata table. By default, they all start with "batch. Batch_job_execution and batch_step_execution are two examples. However, there is a potential need to change the prefix. If the schema name needs to be placed in the table name, or more than one metadata set needs to be placed in the same schema, the table prefix needs to be changed:

In the above example, every request to metadata is named "system. Test _". Batch_job_execution "will be mapped to system. test_job_execution.

Note: Only the table prefix can be configured. The table and column names are not allowed.

4.2.3. Memory-based repository

In some scenarios, you may not want to persistently store domain entities in the database. It may be Speed considerations. It takes some time to store domain entities at each submitted point. Another reason is that you do not need to persist the status of a special task. For these considerations, spring batch provides a task repository with memory ing versions:

Note that the memory repository is unstable, so restarting between JVM instances is not allowed. Likewise, two task instances cannot be started with the same parameters. They are not applicable to multi-threaded tasks or local distributed steps. If you need these features, you need to use the database version.

However, you still need to define a transaction manager because the database is still transactional because of the rollback needs. Many people have found resourcelesstransactionmanager useful for testing purposes.

4.2.4 non-standard database types in the repository

If the database platform you are using is not within the scope of the supported platform, select a supported database type, as long as the SQL syntax is close enough. Try to replace the short attribute declaration with the immature jobrepositoryfactorybean and use it to set the most similar database type:

(Jobrepositoryfactorybean tries to automatically identify the database type from the data source, if it is not specified) the main difference between different platforms is basically a primary key generation policy problem, therefore, it is usually necessary to reload incrementerfactory (using a standard implementation in the Spring framework ).

If you are not using RDBMS, the only choice is to implement the data access layer (DAO) interface that simplejobrepository depends on, use the General spring method to perform manual operations one by one.