Steps involved in J2EE Transaction

To emulate a business transaction, a program may need to perform several steps. A financial program, for example, might transfer funds from a checking account to a savings account, by performing the steps listed in the following pseudocode:

1. begin transaction
2. debit checking account
3. credit savings account
4. update history log
5. commit transaction

In the preceding pseudocode, the begin and commit statements mark boundaries of the transaction. To complete this transaction, all the three steps complete must complete successfully. If all three steps do not complete successfully, data integrity could be compromised.
This guarantee is described as atomicity. A transaction can end in two ways: with

1. a commit or
2. a rollback.

When a transaction commits, the modifications made by statements within the transaction boundaries are saved and made permanent. The changes are durable, that is they will survive future system failures. If any statement within a transaction fails, the transaction rolls back, undoing the effects of all statements executed so far in the transaction. In the pseudocode, for example, if a disk drive crashed during the credit step, the transaction would roll back and undo the data modifications made by the debit statement.
Even if a transaction fails, data integrity would be intact because the transaction accounts still balance. This aspect of transactional behavior is known as transactional consistency.
The transaction service also provides isolation, which means that phases in a transaction cannot be observed by other applications and threads, until the transaction is committed or rolled back. Once a transaction is committed, the committed transaction can be safely observed by applications and threads.