Principles of EJB Transactions

In the first course in this series you learned the principles of distributed transactions. This lesson and the next review these principles.

A transaction is a set of steps, executed in a program, such that the action specified by each and every step must be executed completely, or none of the actions specified by any of the steps will be executed.
This means that when the transaction executes, it executes all of the steps that are involved, or none of the steps. This is known as an atomic unit of work . For this to be the case, all of the events in the transaction must be part of a single thread ofcontrol .

What does this really mean? It means ALL or NOTHING. Let us assume that you want to move $100 from your checking account to your savings account. If you are like me, you will want the following condition to apply:

1. If the $100 is removed from my checking account it must be added to my savings account. If you are the bank you will want the following condition to apply: Only add $100 to the savings account after it has been removed from the checking account.
   To make sure this happens we can wrap up the two steps in a transaction. A transaction is an atomic unit of work. Either it all happens or none of it happens.
   The "begin transaction" tells the environment to start a transaction and that all the steps that follow are part of it. The "commit transaction" is executed after the last step, which tells the environment that all went well and the changes requested in the steps in the transaction can be made permanent.

What happens if the $100 is removed from your checking account and, when the program goes to add it to the savings account, something goes wrong? The bank would love it if the program did nothing at this point; the bank would be up $100 dollars. Your program or the databas can "rollback" the transaction. This will undo all the steps that were executed since the "begin transaction." The $100 would go back into your checking account automatically.

In most Bank Transactionbooks, and historically in our industry, transactions related to Relational Database Management Systems (RDBMS). However, in the world of objects, an object that has a persistent state can be part of a transaction. The persistent state of the object could be stored in an RDBMS, an Object Store, or even in another program.
In the next lesson you will review how transactions work with remote objects.