How to "roll back" changes made by Core Service (WCF transactions)?

Question

A customer has created a "deep copy" type of functionality using the (WCF-based) Core Service, similar to Experience Manager Page Types. The Core Service code clones a given Page, creates copies of its referenced Components, and links the new Page to the new Components.

Does the Core Service supports transactions, where if part of some logic to create Pages and Components fails, you can programatically revert (or prevent) any changes made as part of the same request (as part of a transaction).

I haven't found the term "transaction" online or in the RWS Documentation Center, specifically associated with the Core Service, except in the context of publishing transactions. However, the Core Service (chm) documentation mentions something about WCF flowing the "client transaction to the server" where "it is stored in the Core Service's session state."

Specifically, there's a documented method called EnlistInTransaction() that can have a Core Service client enlist itself in a/the pending transaction.

The Remarks have the following:

When a transactional Core Service method is called, WCF flows the client transaction to the server and it is stored in the Core Service's session state. When a non-transactional (read-only) Core Service method is called, WCF doesn't flow the client transaction to the server, so initially the server is unaware of the context transaction. Particularly, that is a problem in complex scenarios when client application has two or more connections to CoreService and needs to read uncommitted data that were created by one client using the other client connection. In order to overcome that problem, client that is reading uncommitted data should first enlist itself in the perding transaction using this method.

What makes a Core Service method "transactional" and is there an example or documentation on how to revert or cancel a set of multiple changes such as the creation of a new Page and multiple Components?

Perhaps you get a transaction "for free" with a session?

Answer 1

Yes, the Core Service supports transactions. But I wouldn't bother in this case.

There are some potential complications with transactions and they can be really difficult to troubleshoot when they occur. So I would only use them when absolutely necessary.

In this case, I'd say you could just leave the Page and the Components that did get created - and give a clear error message if one or more of them failed to get cloned. Oh and do some pre-checks before attempting the whole thing (i.e. is the user even allowed to create Pages and Components in the target location). That would minimize the chance of any failures and let the user easily fix any problems manually (rather than having to do everything manually in case of some structural issue with one Component).

All that said, if you do wish to use transactions, you will need to use a TransactionScope and make sure you call Complete on it at the end:

using (var scope = new TransactionScope()) 
{
  // Create Page
  // Clone Components...

  // Commit the transaction
  scope.Complete();
}

You will also need to make sure that the binding for the Core Service endpoint that you are using in your client has transaction flow enabled (@transactionFlow="true"). This is only set on the wsHttp bindings by default.

As for what makes a method "transactional", it's basically anything that makes changes (e.g. save and delete). I would say the use case for EnlistInTransaction is pretty narrow (pretty much the exact scenario described in the comment) and it is not relevant in this case.

TLDR: You will get better usability out of making the cloning idempotent as opposed to atomic.