Now that we have looked at the simple atomic approach we can take when dealing with the concurrency of consumption and changes to the persisted data, what happens if this is just too simple for our 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. But if we needed to stop and undo changes we had made part way through an operation, how might we achieve that?

Luckily, drawing on inspiration from traditional roots, Hazelcast provides us with transactional capabilities. Offering a REPEATABLE_READ transaction isolation (the only transactional mode currently supported), once you enter a transaction, Hazelcast will automatically acquire the appropriate key locks for each entry that is interacted with; any changes we write will be buffered locally until the transaction is complete. If the transaction was successful and...