Module 16: Database Integration and Persistence
Transactions and Isolation Levels
Treat transactions as business-protection boundaries, not database ceremony. You will group related statements into one reliable unit, understand rollback behavior, and learn the practical meaning of isolation levels without getting lost in vendor-specific detail.
Author
Java Learner Editorial Team
Reviewer
Technical review by Java Learner
Last reviewed
2026-04-17
Java version
Java 25 LTS
Learning goals
- Place transaction boundaries around true business units of work
- Decide when commit and rollback should happen explicitly
- Understand the common read anomalies that isolation levels are designed to prevent
Before you start
- You are comfortable with classes, exceptions, and writing small multi-class Java programs
Lesson roadmap: Start with the mental model, then follow the design choices, common pitfalls, and the practical workflow you should apply in a real project.
A transaction groups related database operations into one all-or-nothing unit: If one step fails, the whole logical change can be rolled back.
Auto-commit is convenient for single statements but not for multi-step business logic: Transfers, order placement, and state transitions usually need explicit transactions.
Isolation levels trade correctness guarantees against contention and performance: They help decide what kinds of intermediate or conflicting reads are allowed.
Advanced mindset: Think first about business consistency. Isolation is not just a database setting; it is a correctness decision.
Business first: A transaction exists because the business meaning of several statements is “one change.” Transfers, checkout flows, and inventory updates are wrong if only half the work commits.
Rollback is part of the design: Teams often focus on the happy path, but advanced database code is clearer when it explicitly describes which failures should abort the whole unit of work.
Isolation in plain language: Lower isolation can improve throughput but may allow stale or intermediate observations. Higher isolation reduces anomalies but can increase waiting and contention.
Keep transactions short: Open the transaction, do the necessary database work, and commit or roll back. Long transactions hold locks and connections longer than the system can usually afford.
How to study this module: Keep a simple domain in mind, such as users, orders, or tasks. It is easier to understand JDBC, transactions, and ORM mapping when every SQL statement serves a clear business action.
Code review mindset: Database code is not only about “does it work.” Reviewers also look for resource safety, transaction boundaries, predictable query counts, and whether the persistence layer leaks too much SQL detail into higher layers.
Production habit: Measure query behavior early. Slow queries, long transactions, and leaked connections usually hurt real systems more than syntax mistakes do.
Runnable examples
A manual transaction boundary
connection.setAutoCommit(false);
try {
// statement 1
// statement 2
connection.commit();
} catch (Exception ex) {
connection.rollback();
}Expected output
Either both statements succeed together or the transaction rolls back.
Two statements belong in one business transaction
connection.setAutoCommit(false);
try {
// subtract from source account
// add to destination account
connection.commit();
} catch (SQLException ex) {
connection.rollback();
throw ex;
}Expected output
The transfer succeeds as one unit or the database returns to the previous consistent state.
Common mistakes
Including long-running network calls inside a database transaction
Keep the transaction focused on the database work so locks and connections are held for the shortest safe time.
Assuming rollback always happens automatically for every failure path
Know the behavior of your framework or manual code path and test failure cases intentionally.
Mini exercise
Design a transaction for “place order.” List the statements that belong inside it, the validation that can happen before it, and one external call you would keep outside the transaction.
Summary
- Transactions keep related changes consistent.
- Commit and rollback should be explicit in multi-step operations.
- Isolation levels define what concurrent readers and writers may observe.
- Transaction boundaries should match business meaning, not method length.
- Isolation is a correctness and contention trade-off, not a number to copy from a tutorial.
Next step
After raw SQL and transactions, step up one level to ORM-style mapping with JPA.
Sources used