المعاملات (Transactions) من Java

Written Explanation

Auto-commit: every statement on its own

A new JDBC Connection starts in auto-commit mode: each statement is committed as soon as it finishes. That is convenient for one statement, and dangerous for two that belong together. If statement 2 fails, statement 1 is already permanent.

Here is the naive borrow method. It has no transaction:

public void borrowNaive(Connection conn, int bookId, int memberId) throws SQLException {
    run(conn, INSERT_LOAN, bookId, memberId);   // INSERT INTO loans ...
    run(conn, DECREASE_COPIES, bookId, -1);     // UPDATE books SET copies = copies - 1 ...
}

where run is a small helper that prepares, binds, and calls executeUpdate() (the full class is in the examples). Borrow a book whose copies is already 0 and the CHECK constraint rejects the update. By then the loan row is committed.

The transaction pattern

conn.setAutoCommit(false);
try {
    // statement 1
    // statement 2
    conn.commit();
} catch (SQLException e) {
    conn.rollback();
    throw e;
} finally {
    conn.setAutoCommit(true);
}

Step by step:

• setAutoCommit(false) starts a manual transaction: nothing is permanent until you say so.
• commit() makes all changes since the last commit permanent, together.
• rollback() undoes all changes since the last commit.
• The catch rolls back and rethrows, so the caller still learns the operation failed. Rolling back and then swallowing the exception would hide the failure.
• The finally restores auto-commit. The Java tutorial advises keeping auto-commit off only for the duration of the transaction, because a long-open transaction can hold up other users. If the connection came from somewhere else and might be used again, restore the previous setting (getAutoCommit() first), as the full example does.

The tutorial also points out that when an SQLException occurs partway through, you cannot tell from the exception which statements went through, so calling rollback() is the reliable way to leave nothing partial behind.

Other connections do not see your uncommitted work

PostgreSQL's documentation says an open transaction's updates are invisible to other transactions until it completes, and then they appear all at once. That is the "all-or-nothing" promise as seen from outside. Example 3 shows it with two Connection objects.

A failed statement poisons the transaction

In PostgreSQL, once a statement fails inside a transaction, the transaction is aborted: every later statement is refused until you roll back. In our run the next SELECT 1 got ERROR: current transaction is aborted, commands ignored until end of transaction block. So never "ignore the error and carry on" inside a transaction: roll back, then decide what to do.

Where the transaction boundary lives

A Connection holds one transaction at a time. That is why the methods in lesson 3 took the connection as a parameter: the caller (here, LoanService.borrow) owns the connection and the transaction, and the repository methods just run statements on it. The next demo lessons build on that split.