- 전체
- JAVA 일반
- JAVA 수학
- JAVA 그래픽
- JAVA 자료구조
- JAVA 인공지능
- JAVA 인터넷
- Java Framework
- Java GUI (AWT,SWING,SWT,JFACE)
- SWT and RCP (web RAP/RWT)[eclipse], EMF
JAVA 자료구조 Spring Batch Goodies With MongoDB
2020.09.21 22:01
Spring Batch Goodies With MongoDB
Explore a tutorial that explains what needs to be done in order to get spring batch goodies along with MongoDB.
In this article, I am going to explain what needs to be done in order to get spring batch goodies along with MongoDB. I assume that the reader has basic knowledge about spring boot, spring batch, MongoDB, and Java 8.
Let's start!
Motivation
In my previous article I showed how to implement an application that replicates one database into local MongoDB instance using spring batch. Now, I want to show what interfaces needs to be implemented in order to have all the details regarding batch itself. Spring batch gives all the information out of the box, but I could not fing the default mechanism to store them into the MongoDB database. After some research, I found this repository that I used as my starting point.
Preconditions
System requirements:
-
- Java 8
- Maven 3.5.2
- Spring Boot 1.5.10
- MongoDB 3.4.
Here are the dependencies defined in pom.xml:
This is a Spring Boot application with spring batch and MongoDB starters.
Implementation and Explanation
Let's see the batch configuration in class MainBatchConfigurer:
The configuration was done based on the documentation that I found on the Spring page. The MainBatchConfigurer is spring configuration class that implements interface BatchConfigurer from spring package. Spring documentation says:
The core interface for this configuration is theBatchConfigurer. The default implementation provides the beans ... and requires aDataSourceas a bean within the context to be provided. This data source will be used by theJobRepository.
BatchConfigurer requires following definitions:
-
- job repository
- transaction manager
- job launcher
- job explorer
These definitions are mandatory, but we do not have to think about how to implement them. Spring contains default implementations for each of them. What is important here is that the job repository and job explorer need implementation of interfaces ExecutionContextDao, JobExecutionDao, JobInstanceDao, and StepExecutionDao. Also, when SimpleJobLauncher is created, it is very important to call method afterPropertiesSet after the job launcher is fully created. SimpleJobLauncher requires a fully defined job repository. As spring documentation says:
"...theJobRepositoryis used for basic CRUD operations of the various persisted domain objects within Spring Batch, such asJobExecutionandStepExecution. It is required by many of the major framework features, such as theJobLauncher,Job, andStep."
In this particular case, I do not need any kind of transaction handling, so I'm using ResourcelessTransactionManager. If one needs complex transaction handling, then proper implementation should be chosen. When it comes to JobExplorer, the documentation says:
"...JobExploreris a read-only version of theJobRepository..."
Now, lets see the interface that has to be used in order to store batch details into the database. First, I want to show ExecutionContextDao. It contains the following methods:
No magic here. The interface clearly shows what has to be done here. So, let's take a look at the implementation.
What needs to be done here is to implement all the methods that save ExecutionContext based on JobExecution and StepExecution. This has to be done manually. To save ExecutionContext as a MongoDB document private method, saveOrUpdateExecutionContext was implemented. What it does is extracts parameters from ExecutionContext, puts them into the MongoDB document, and stores that document into MongoDB. The other method worth mentioning here is private method getExecutionContext. This method does exactly the opposite of what saveOrUpdateExecutionContext does. It gets the raw document from the collection named "ExecutionContext" (check method getCollection) and converts it into object ExecutionContext.
Now, let us look closer into the interface JobInstanceDao. The interface contains the following methods:
The above methods manage JobInstance on a database level. Below is the implementation:
What all the above methods do is create a single JobInstance as a document, store that document in a collection named "JobInstance," and gets a single JobInstance from that collection and maps raw documents into the JobInstance object. Also, there is a method that creates a job key based on job parameters. The outcome from this class is a MongoDB collection "JobInstance" full of documents with job details.
The next interface that I would like to shortly describe is JobExecutionDao. This interface contains the following methods:
The names of the method are self-explanatory. Only the method synchronizeStatus can be a bit mysterious. The idea behind this method is:
Because it may be possible that the status of a JobExecution is updated while running, the following method will synchronize only the status and version fields.
So, knowing that, let's have a look at the implementation of this interface for the MongoDB database:
Similarly to previous implementations, MongoJobExecutionDao does CRUD operations on JobExecution object (except D). The above methods convert JobExecution to a MongoDB document and store that document to the database and also converts raw MongoDB documents to the JobExecution object when read from the database. The outcome of this implementation of JobExecutionDao is a MongoDB collection named "JobExecution," which is full of documents containing job execution details.
Last but not least, let's look at interface StepExecutionDao. It contains the following methods:
As you can see, it is also uses CRUD (without D). Lets have a closer look at the implementation of this interface.
Nothing new here. This implementation converts StepExecution object to a MongoDB document when saving and raw document to StepExecution object when reading from the database. The outcome of this implementation is a MongoDB collection named "StepExecution," which is full of documents containing details of step execution.
There is one class left to show. All of the above implementations extend abstract class AbstractMongoDao. So lets look at this class:
This abstract class contains all the constants and methods used by its children. The constants are mainly the names of the attributes relevant to the proper dao interface. These constants are used as keys under which data are stored. Here also, MongoTemplate is autowired. There are also some utils methods that help with processing data.
Connection to the MongoDB database is defined in MongoDBConfig class.
And that is it!
Summary
In this tutorial, I showed you how I used spring batch with mongodb. and how spring batch goodies can be saved and read from MongoDB. The full code is available on Github. The code and this article were built based on the spring-batch and springbatch-mongoDao repositories. I hope this tutorial was helpful.
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.
댓글 0
| 번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
|---|---|---|---|---|
| 6 |
java4autocad Java for Autocad
| 졸리운_곰 | 2017.04.26 | 387 |
| 5 | Java3D and Eclipse | 졸리운_곰 | 2015.08.12 | 317 |
| 4 |
Draw2d Intro
| 졸리운_곰 | 2015.07.29 | 514 |
| 3 |
FreeLayout: A New Java Layout
| 졸리운_곰 | 2015.05.14 | 315 |
| 2 |
XML file to Treeviewer
| 졸리운_곰 | 2015.03.19 | 399 |
| 1 |
Java GUI(AWT) 프로그래밍
| 졸리운_곰 | 2015.03.09 | 938 |

