SharePoint does not provide transaction (rollback and commit) support on List data operations. What are the workarounds to achieve transactional behavior.
Use case 1:
When an item is added in a List I want to update another List item. But if the update fails I want to rollback the item added to the first list.
Use case 2:
Updating 10 List items programatically. If 10th update fails, I want to rollback previous 9 updates.
Although SharePoint List are not relational database and should not be as a relational database, developers are increasingly using it for storing business critical data (which needs data integrity) and they are discouraged to use External List because it poses lots of restrictions on the features available on normal Lists.
Since SPLists don’t provide inherent support for transactions, you have to handle rollback operations yourself.
In both use cases 1 and 2, the easiest way to simulate a transaction is to read in the state of any list item you are changing prior to executing an update, and then write that state back should you detect a failure. It’s not a perfect solution, since a sufficiently severe error might prevent your rollback updates as well. That’s the price you pay for not having the data store support transactions.
That being said, while it’s true many clients will ask for business critical data to be stored in SPLists, I would argue that it’s your job to convince them that it’s not a good idea, and that transactional databases accessed over webservices are a much safer SP compatible way to store important data.