#springbatch #mongodb #nosql
Spring Batch is a Spring-based framework for enterprise Java batch processing. An important aspect of Spring Batch is the separation between reading from and writing to resources and the processing of a single record, called item in the Spring Batch lingo. There are a lot of existing item readers and writers for a wide range of resources like JDBC databases, JMS messaging systems, flat file etc. If the resource of your choice is not supported of of the box, it is easy to implement your own reader and writer as we will see in a minute.
MongoDB is a popular NoSQL datastore. It stores so called documents (basically an ordered set of key/value pairs where a value can be a simple data type like String or integer but also an array of values or a sub document). MongoDB is optimized for heavy write throughput and horizontal scaling.
Since I am a big fan of MongoDB on the one hand and introducing the Spring Batch framework at one of my customers on the other hand, why not implement a Spring Batch item reader and writer for MongoDB and publish it on github so that everybody can use it: github.com/ttrelle/spring-batch-mongodb-support.
Today something completely different: I’ll interview Oliver Gierke from SpringSource. He we go …
Tobias Trelle: Hi Oliver. Would you mind introducing yourself to listeners that might not already know you.
Oliver Gierke: My name is Oliver Gierke. I work for the SpringSource division of VMware as part of the Spring Data engineering team. I am responsible for the core, the JPA and the MongoDB modules of the project. Beyond that I organize the releasemanagement of all Spring Data modules that build on top of the core module and travel conferences and user groups quite a lot to spread the word.
Before that I worked as architect and developer in banking and automotive industry for quite a few years. I am also part of the JPA expert group.
TT: How did you actually get to SpringSource and the Spring Data project?
OG: My former employer, Synyx GmbH & Co. KG in Karlsruhe has been using open source software technology quite heavily to implement their customer projects. This included that we – as far as customers allowed – extracted libraries from the projects and published them under an open source license. One of these libraries was called Hades. It was based on an article at IBM DeveloperWorks and another one by Eberhard Wolff in German Java Magazine, which both defined ideas how to significantly reduce the amount of code to implement data access layers with Hibernate and JPA.
In this article, I’m going to sketch a pattern for implementing pessimistic locking with MongoDB. MongoDB is a document-orientated NoSQL datastore that does not support locking itself.
In some business processes it may be required that you have an exclusive access to a single document. That’s when you need something like pessimistic locking.
The implementation should offer the following features:
- Locking does not change the locked document itself
- Locks can be removed manually or by a timeout
For the rest of this article, let’s assume we want to lock documents in a collection called
The basic idea is to maintain a separate collection holding the locks, e.g.
workitem.lock. The schema of a lock may look like this: