Now that we have looked at the simple atomic approach that we can take when dealing with the concurrency of consumption and changes to the persisted data, let's address the following question: What happens if this approach is just too simple for a use case? Well, now that we have the ability to lock both globally across the cluster and on individual data items, we can prevent unexpected changes to our supporting data in the middle of an operation. However, what do we do if, partway through the operation, we need to stop and undo the changes that we made?

Luckily, drawing inspiration from the traditional roots, Hazelcast provides us with transactional capabilities via the REPEATABLE_READ transaction isolation (the only transactional mode that is currently supported). Once you enter a transaction, Hazelcast will automatically acquire the appropriate key locks for each entry that it interacted with. Any changes that we write will be buffered locally until the transaction...