What are the workarounds for missing transactions (rollback and commit) support on SharePoint Lists?

S开发者_如何学运维harePoint 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.

I find it's a little simpler if you use lists that support versioning. I use a intermediary class to access list items. When I call .Update() on that class, I store the current version id of any item that I am updating. If anything goes wrong later in the "transaction" I simply revert back to that version id.