Showing results for 
Search instead for 
Did you mean: 

SDK - Allow explicit transaction managemement


from an xRM perspective, one of the most important, missing features from the SDK is the ability to begin a transaction, put several insert/updates/deletes/SetState/whathever in it, then commit / rollback explicitly.

When you use Microsoft Dynamics as xRM, developing any kind of custom app on it, often you need to perform several operations through a custom UI (such as updating or creating several records providing progress feedback to the user) that must be consistent. If you are creating 100 records, and the 97th one fails for wathever reason, often you need to rollback all the changes made by the previous data...

Currently this is not possible, unless using some sort of compensating BL that won't work if the cause of the error is a network issue. In this case, data already in MSCRM will be in an inconsistent state, and must be recovered manually.

The only way, right now, to be sure that an all-or-none pattern is applied is to put the "maxi-operation" within a plugin, but it has some side effects:
1- if the plugin is synchronous, and it must execute many operations, it causes a server side timeout (and you can't do a thing about it)
2- no user feedback is provided until the whole operation is completed. The system looks like frozen, and the user is scaried
3- it locks database tables, so no-one else can execute writes in parallel.

It's a pain for ISVs that cannot grant the reliability of their own solutions out of the box... and it's a problem that custom dev faced and solved two decades ago 🙂

Having some sort of MSDTC working against MSCRM will be a biggest enhancement for the whole xRM platform. It will allow us to extend CRM in ways no one can predict, without the headache due to inconsistency and error management.

I think this really will be the killer feature that can allow MSCRM to become the best of breed of the xRM platforms.

Thank you,

Status: Under Review
Regular Visitor
Status changed to: Under Review
Regular Visitor
I see two major difficulties with allowing this sort of transaction management: 1. Any reliable transaction management has to lock the updated data for the duration of the transaction. If you allow client interaction durign the transaction, the server will have to maintain the locks until it receives an explicit commit from the client. This could significantly increase the duration of locks, this impacting overall performance. You also have to consider what happens if the client doesn't send the explicit commit - do the locks get held, or does the transaction rollback automatically after a period of time. Neither are ideal 2. It must be possible to rollback a transaction. This would have to include any changes caused by plugins firing on the affected entities. I cannot see a way to ensure that changes made by plugins can be rolled back, especially as a) the plugins may be written by 3rd parties or b) the plugins may modify external systems Either of these has the potential to introduce serious problems, so I don't see that MSCRM would be able to provide robust, client-controlled transactions
Regular Visitor
Thank you for your feedback. This is a great suggestion, and we will consider this in our roadmap.
Regular Visitor
Hi David, as I wrote, the problems you figured out are the same that me and my dev team are struggling with when we develop custom apps or custom services working on databases. There is a lot of literature on this argument, including how to handle with transaction in complex business cases scenarios. The problem is not the knife. The knife is a tool, the knife is harmfull. Is how people use the knife that could cause problems. Would you remove all the knifes from earth for this reason? Let's give people tools, and let them be responsible of how they use them. My 2 cents