Using CMS APIs in transaction (scope)

Zsolt Nemeth

Vote:

Hi,

Using CMS 11.37, Commerce 13.34.

I would like to encapsulate CMS content manipulation (IContentRepository and co.) calls in transactions, but I cannot find an official way to do that.

Found that IContentRepository (CMS) uses EPiServer.Data.Providers.Internal.ConnectionContext, but it is an internal API, I am afraid it is not a good idea to use that.

Commerce uses Mediachase.Data.Provider.TransactionScope, that one is working fine and it is a public API.

Using MSDTC/System.Transaction.TransactoinScope is problematic as of additional configuration required on all sides.

Reason we need a transaction for is that we have a custom automatic content migration system and it would be great if in case of errors current job would be rolled back, otherwise problematic to reexecute it.

Any ideas or best practices?

Thanks,

Zsolt

#326045

Jul 26, 2024 7:28

Stefan Holm Olsen

Vote:

I don't think you can. And it could potentially drag down the platform, if you found a way and did it anyway.

Have you considered hooking into events in IContentEvents? If you are concerned that the external API can be down during handling such an event, you can use a queue (either a table in the database, a Service Bus, an Event Grid or Hangfire) to store each event and ensure each event is exported exactly once.

#326100

Jul 27, 2024 9:33

Zsolt Nemeth

Vote:

Problem is currently, that if any content migration job fails, leaves an inconsistent state, that is why a rollback would be great. Using a load balanced on premise system - I don't see how hooking into with IContentEvents would solve the problem, I would like a transaction around insert/update/delete statements for both CMS and Commerce operations.

#326614

Aug 06, 2024 13:00