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
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:
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[1] and must support distributed transactions[2].
1) Starts a transaction
2) Temporarily debit the checking account with $100
3) Temporarily credit the $100 to the savings account
4) If there were no problems permanently update the accounts
In Java EE 8, the modern equivalent of managing transaction isolation levels is primarily handled through:
JDBC (still relevant for programmatic control), and
JTA (Java Transaction API) and annotations in Jakarta EE / Java EE, especially with CDI and EJB or JPA.
JDBC (still supports same isolation levels)
The isolation levels from SQL-92 are still used unchanged:
These are exactly the same as in legacy J2EE, because JDBC hasn't changed these.
JTA in Java EE 8 (via annotations)
If you're using container-managed transactions with Enterprise Java Beans (EJB) or JPA, you don't set isolation levels directly in code, the container (i.e., the app server) handles that, often configured in:
persistence.xml (for JPA)
Server-specific deployment descriptors
Or overridden via javax.transaction.Transactional
However, Java EE 8 doesnât natively support isolation level declarations via annotations like Spring does (@Transactional(isolation=...)). But app servers may allow it via proprietary configuration.
Modern Java EE 8 Best Practices
In Java EE 8:
Use JTA for transaction boundaries.
Isolation levels are generally configured at the data source level or through container configuration (like in GlassFish, WildFly, etc.).
With JPA, you rely on the underlying database and provider (e.g., EclipseLink, Hibernate) for isolation semantics.
If Using Spring with Java EE 8 Spring's @Transactionaldoes support specifying isolation levels:
@Transactional(isolation = Isolation.SERIALIZABLE)
public void doSomething() {
// business logic
}
Summary Table
Concept
Legacy J2EE (2001)
Java EE 8 Modern Equivalent
Transaction Isolation Levels
SQL-92 + JDBC constants
Still SQL-92 + JDBC constants
Programmatic control
conn.setTransactionIsolation(...)
Still same in JDBC
Declarative Transactions
EJB + JTA
JTA (@Transactional), container-managed
Isolation config
Set in code or via server config
Prefer server config or JPA provider
If you're targeting Jakarta EE 9+, it's basically the same, just with `jakarta.transaction` namespace instead of `javax.transaction`.
Transaction Rollback
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.
RDBMS
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.
[1]Transaction aware: An environment that supports transactions.
[2]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.