Transactionally rolling on
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 ...