EventGet 50% off your ticket to MongoDB.local NYC on May 2. Use code Web50!Learn more >>
MongoDB Developer
Java
plus
Sign in to follow topics
MongoDB Developer Centerchevron-right
Developer Topicschevron-right
Languageschevron-right
Javachevron-right

Java - Change Streams

Maxime Beugnet11 min read • Published Feb 01, 2022 • Updated Mar 01, 2024
MongoDBChange StreamsJava
Facebook Icontwitter iconlinkedin icon
Rate this quickstart
star-empty
star-empty
star-empty
star-empty
star-empty

Updates

The MongoDB Java quickstart repository is available on GitHub.

February 28th, 2024

  • Update to Java 21
  • Update Java Driver to 5.0.0
  • Update logback-classic to 1.2.13

November 14th, 2023

  • Update to Java 17
  • Update Java Driver to 4.11.1
  • Update mongodb-crypt to 1.8.0

March 25th, 2021

  • Update Java Driver to 4.2.2.
  • Added Client Side Field Level Encryption example.

October 21st, 2020

  • Update Java Driver to 4.1.1.
  • The Java Driver logging is now enabled via the popular SLF4J API, so I added logback in the pom.xml and a configuration file logback.xml.

Introduction

Java badge
Change Streams were introduced in MongoDB 3.6. They allow applications to access real-time data changes without the complexity and risk of tailing the oplog.
Applications can use change streams to subscribe to all data changes on a single collection, a database, or an entire deployment, and immediately react to them. Because change streams use the aggregation framework, an application can also filter for specific changes or transform the notifications at will.
In this blog post, as promised in the first blog post of this series, I will show you how to leverage MongoDB Change Streams using Java.

Getting Set Up

I will use the same repository as usual in this series. If you don't have a copy of it yet, you can clone it or just update it if you already have it:
If you haven't yet set up your free cluster on MongoDB Atlas, now is a great time to do so. You have all the instructions in this blog post.

Change Streams

In this blog post, I will be working on the file called ChangeStreams.java, but Change Streams are super easy to work with.
I will show you 5 different examples to showcase some features of the Change Streams. For the sake of simplicity, I will only show you the pieces of code related to the Change Streams directly. You can find the entire code sample at the bottom of this blog post or in the Github repository.
For each example, you will need to start 2 Java programs in the correct order if you want to reproduce my examples.
  • The first program is always the one that contains the Change Streams code.
  • The second one will be one of the Java programs we already used in this Java blog posts series. You can find them in the Github repository. They will generate MongoDB operations that we will observe in the Change Streams output.

A simple Change Streams without filters

Let's start with the most simple Change Stream we can make:
As you can see, all we need is myCollection.watch()! That's it.
This returns a ChangeStreamIterable which, as indicated by its name, can be iterated to return our change events. Here, I'm iterating over my Change Stream to print my change event documents in the Java standard output.
I can also simplify this code like this:
I will reuse this functional interface in my following examples to ease the reading.
To run this example:
  • Uncomment only the example 1 from the ChangeStreams.java file and start it in your IDE or a dedicated console using Maven in the root of your project.
  • Start MappingPOJO.java in another console or in your IDE.
In MappingPOJO, we are doing 4 MongoDB operations:
  • I'm creating a new Grade document with the insertOne() method,
  • I'm searching for this Grade document using the find() method,
  • I'm replacing entirely this Grade using the findOneAndReplace() method,
  • and finally, I'm deleting this Grade using the deleteOne() method.
This is confirmed in the standard output from MappingJava:
Let's check what we have in the standard output from ChangeStreams.java (prettified):
As you can see, only 3 operations appear in the Change Stream:
  • insert,
  • replace,
  • delete.
It was expected because the find() operation is just a reading document from MongoDB. It's not changing anything thus not generating an event in the Change Stream.
Now that we are done with the basic example, let's explore some features of the Change Streams.
Terminate the Change Stream program we started earlier and let's move on.

A simple Change Stream filtering on the operation type

Now let's do the same thing but let's imagine that we are only interested in insert and delete operations.
As you can see here, I'm using the aggregation pipeline feature of Change Streams to filter down the change events I want to process.
Uncomment the example 2 in ChangeStreams.java and execute the program followed by MappingPOJO.java, just like we did earlier.
Here are the change events I'm receiving.
This time, I'm only getting 2 events insert and delete. The replace event has been filtered out compared to the first example.

Change Stream default behavior with update operations

Same as earlier, I'm filtering my change stream to keep only the update operations this time.
This time, follow these steps.
  • uncomment the example 3 in ChangeStreams.java,
  • if you never ran Create.java, run it. We are going to use these new documents in the next step.
  • start Update.java in another console.
In your change stream console, you should see 13 update events. Here is the first one:
As you can see, we are retrieving our update operation in the updateDescription field, but we are only getting the difference with the previous version of this document.
The fullDocument field is null because, by default, MongoDB only sends the difference to avoid overloading the change stream with potentially useless information.
Let's see how we can change this behavior in the next example.

Change Stream with "Update Lookup"

For this part, uncomment the example 4 from ChangeStreams.java and execute the programs as above.
I added the option UPDATE_LOOKUP this time, so we can also retrieve the entire document during an update operation.
Let's see again the first update in my change stream:
Note: The Update.java program updates a made-up field "comments" that doesn't exist in my POJO Grade which represents the original schema for this collection. Thus, the field doesn't appear in the output as it's not mapped.
If I want to see this comments field, I can use a MongoCollection not mapped automatically to my Grade.java POJO.
Then this is what I get in my change stream:
I have shortened the comments field to keep it readable but it contains 14 times the same comment in my case.
The full document we are retrieving here during our update operation is the document after the update has occurred. Read more about this in our documentation.

Change Streams are resumable

In this final example 5, I have simulated an error and I'm restarting my Change Stream from a resumeToken I got from a previous operation in my Change Stream.
It's important to note that a change stream will resume itself automatically in the face of an "incident". Generally, the only reason that an application needs to restart the change stream manually from a resume token is if there is an incident in the application itself rather than the change stream (e.g. an operator has decided that the application needs to be restarted).
For this final example, the same as earlier. Uncomment the part 5 (which is just calling the method above) and start ChangeStreams.java then Update.java.
This is the output you should get:
As you can see here, I was able to stop reading my Change Stream and, from the resumeToken I collected earlier, I can start a new Change Stream from this point in time.

Final Code

ChangeStreams.java (code):
Remember to uncomment only one Change Stream example at a time.

Wrapping Up

Change Streams are very easy to use and setup in MongoDB. They are the key to any real-time processing system.
The only remaining problem here is how to get this in production correctly. Change Streams are basically an infinite loop, processing an infinite stream of events. Multiprocessing is, of course, a must-have for this kind of setup, especially if your processing time is greater than the time separating 2 events.
Scaling up correctly a Change Stream data processing pipeline can be tricky. That's why you can implement this easily using MongoDB Triggers in MongoDB Realm.
You can check out my MongoDB Realm sample application if you want to see a real example with several Change Streams in action.
If you want to learn more and deepen your knowledge faster, I recommend you check out the M220J: MongoDB for Java Developers training available for free on MongoDB University.
In the next blog post, I will show you multi-document ACID transactions in Java.

Facebook Icontwitter iconlinkedin icon
Rate this quickstart
star-empty
star-empty
star-empty
star-empty
star-empty
Related
Tutorial

Kafka to MongoDB Atlas End to End Tutorial


Jun 07, 2023 | 6 min read
Article

How Queryable Encryption Can Keep James Bond Safe


Sep 29, 2022 | 2 min read
Quickstart

Java - Mapping POJOs


Mar 01, 2024 | 5 min read
Tutorial

Getting Started With Azure Spring Apps and MongoDB Atlas: A Step-by-Step Guide


Jan 27, 2024 | 5 min read
Table of Contents