Hi there
Business data uses an **optimistic locking** approach: so it gives you many possibilities for save update/write/merge scenarios
https://developer.axonivy.com/doc/latest/DesignerGuideHtml/ivy.datamodeling.html#ivy-businessdata-concept
This is why we can provide rock solid persistence mechanisms reflected by multitudes of write methods (save, update, overwrite): https://developer.axonivy.com/doc/latest/PublicAPI/ch/ivyteam/ivy/business/data/store/BusinessDataRepository.html
![alt text][1]
So I guess you are looking for the update() method which provides the richest capabilities to react on persistence failures.
If you have the rollback of non-atomar write operations in mind, then it is a very different case. To support this would be a paradigm break for optimistic locking. As optimistic locking is designed to get rid of all the problems of classical tx based write scenarios.
So basically if you have list of objects that belongs together for being in a consistent state, it should also be shared in the same businessData object.
But maybe we clarify this better with a concrete data model. Feel free to share it :-)
[1]: https://answers.axonivy.com/upfiles/businessDataRepo_update.png
