|
|
|
This is a perfect example of FairCom responding to a request from a customer. We have added the ability to perform a type of Independent Parallel Transaction. In traditional database methodology, this ability might not exist, yet special customer circumstance justified the implementation of this new feature. After you have “begun” a transaction (Transaction A), and then performed some operations, you may now “begin” what we call an Independent Parallel Transaction (Transaction B). When this secondary transaction is committed or aborted, only the operations performed within that transaction are affected. Operations performed within the primary transaction (Transaction A) retain their traditional scope.
In one customer’s case, they wanted to create new files while inside a transaction. These new files were not necessarily part of the atomicity requirements of the primary transaction, yet if the primary transaction was aborted, the creation of these file was also being reverted. Now, within the primary transaction, the customer initiates an Independent Parallel Transaction, performs the create for the files, and then commits the Independent Parallel Transaction. If the primary transaction is later aborted, the abort does not affect these newly created files.
