A critical part of any application is to ensure that any operations it performs are performed correctly. If an application were to only partially complete an operation, then the state of the application would not be correct. For example, look at the problem of a banking application that moved money from one account to another. If the money is taken out of one account and then something happens and the money can not be added to the other account, then the state of the application is not correct. It is said to have lost integrity.
There are two ways to combat this. In the traditional programming model, the developer must anticipate any way that the operation could fail. From any point of failure, the developer must then add support to return the application to the state it was in before the operation was started. In other words, the developer has to add the code to support a rollback of the operation from any point that it could fail.
The other, and much easier way to do this, is for the operation to take place within the environment of a transaction processing system. The job of the system is to ensure that the entire operation, the transaction, completes successfully. If it does, then the changes in the application state are committed to the system, and the user can proceed to their next task. If any part of the operation does not complete successfully, which would leave the system in an invalid state, then the system has to put the application back into its original state. The power of a transaction processing system is that the knowledge to perform these operations is inherent in the system itself. The developer does not have to explicitly support the rollback of any part of the transaction. In fact, all the developer has to do is have each component of the transaction let the system know if it was successful or not. The transaction processing system takes care of the rest.