|Lesson 9||J2EE Transactional environment |
|Objective||Describe a transactional environment. |
J2EE Transactional Environment
A J2EE 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 are executed.
Understanding transactions using an example
That 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:
- 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, and tells the environment that all went well and the changes requested can be made permanent.
An environment that allows you to do this is known as transaction aware
and must support
What happens if the $100 has been 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; they would be up $100!
Your program or the database can "rollback" the transaction, which will cause all the steps which had been executed since the "begin transaction" to be undone.
This would mean that the $100 would be put back into your checking account automatically.
Any interested party that is aware of the transaction, such as the remote object, the database, or the container, can request a rollback of the transaction.
Errors in the transport will cause exceptions to be thrown that will be caught by the container or database, which will then rollback the transaction.
In most textbooks, and historically in our industry, transactions have 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 an RDBMS, an Object Store, or even another program.
More on this in Part 2 of this course. In the next lesson, you will be introduced to how transactions work with remote objects.
Transaction aware: An environment that supports transactions.
Distributed transaction: If a transaction is started on a specific system and all requests to other remote objects maintain and propagate that transaction, the environment is said to support distributed transactions.