In this post I want to give you an insight into the architecture of CenterDevice, a document management and collaboration tool for the enterprise hosted in our own cloud datacenter in Germany. CenterDevice is a startup of codecentric, with a few codecentrics working full or part time on it.
Let me start with a screenshot from our AppDynamics monitoring.
#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.
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: