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?