On Wed, Aug 29, 2012 at 2:32 AM, Willem van der Westhuizen <wavdwesthuizen@gmail.com> wrote:
We are using exist for developing fairly substantial web applications, and are looking for ways to implement a form of two phase commit function in which we can "roll back" changes made to the database to a given point, should an error occur, or the logic of the application requires it such as when a secondary call to some external system fails.

Three questions:
1. Has anybody implemented such a type of solution that we can draw from?

my guess, no. It unique for each application.
 
2. Is such functionality somewhere on the exist development path?

Well, it part of application level, IMHO.
 
3. What would the possibilities and limitation be to implement such a solution using the versioning module in exist in the following type of way.

How atomic your operation(s)? Is it one document change or set of documents?
 
 a. Add a flag to the try/catch function indicating that a transaction should be started. (this might be passing a guuid value that would be used as the transaction id)
 b. A transaction ID will be generated, which can be retrieved as a special variable.
 c. The update and store functions might be updated to take another parameter, the transactionID. In this case, the update will do two things, create a new version of the document being updated and return the documentId, and version number of the old and new versions where applicable. Ideally these would be mapped/indexed internally so that a rollback of the changes would return to the version of the document prior to the changes for each of the documents affected in the order affected. It should also lock the new version until the transaction has been committed. Ideally, it should be possible for the calling query to extract these parameters for each change so that cases where transactions need to span multiple instances of exist running for instance on two servers could be linked into one transaction. However, it might be simpler to only expose the various document IDs and version numbers to the user, so that the user could manually implement a rollback function.
 d. What would be the feasibility and potential risks and penalties be using such an approach?

It is not easy for us to imagine the level of complexity involved in implementing such a capability. Any ideas?

--
Dmitriy Shabanov