Read-only transactions in Spring Boot - Step-by-Step Execution

Concept Flow - Read-only transactions

Start method call

↓

Begin transaction

↓

Set transaction read-only = true

↓

Execute database operations

↓

Check for write attempts

↓

Commit transaction

↓

End method

This flow shows how a read-only transaction starts, runs database reads, prevents writes, and commits or rolls back accordingly.

Execution Sample

Spring Boot

@Transactional(readOnly = true)
public List<User> getUsers() {
    return userRepository.findAll();
}

This method runs inside a read-only transaction to fetch users without allowing data changes.

Execution Table

Step	Action	Transaction State	Write Attempt	Result
1	Method getUsers() called	No transaction	No	Start transaction
2	Begin transaction	Active, read-only=true	No	Transaction started as read-only
3	Execute userRepository.findAll()	Active, read-only=true	No	Data read from DB
4	Attempt to write data (if any)	Active, read-only=true	Yes	Error or rollback triggered
5	Commit transaction	No transaction	No	Transaction committed
6	Method ends	No transaction	No	Transaction closed

💡 Transaction ends after commit or rollback; no writes allowed in read-only mode

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	Final
transactionState	No transaction	Active, read-only=true	Active, read-only=true	No transaction	No transaction
writeAttempt	No	No	No	No	No or Error if attempted

Key Moments - 3 Insights

Why does the transaction prevent data writes even if the code tries to save or update?

Because the transaction is marked read-only (see execution_table step 4), the database or framework blocks write operations to protect data integrity.

What happens if a write is attempted inside a read-only transaction?

An error is thrown or the transaction rolls back immediately, as shown in execution_table step 4, preventing any data changes.

Does a read-only transaction still open a database transaction?

Yes, it opens a transaction but with a read-only flag (execution_table step 2), optimizing for reads and disallowing writes.

Visual Quiz - 3 Questions

Look at the execution_table, what is the transaction state after step 3?

A Active, read-only=true

B No transaction

C Active, read-write

D Rolled back

💡 Hint

Check the 'Transaction State' column at step 3 in the execution_table.

At which step does the transaction commit if no writes occur?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look for the 'Commit transaction' action in the execution_table.

If a write attempt happens at step 4, what is the expected result?

A Transaction commits successfully

B Error or rollback triggered

C Transaction ignores the write

D Transaction converts to read-write

💡 Hint

See the 'Result' column at step 4 in the execution_table.

Concept Snapshot

@Transactional(readOnly = true) marks a method's transaction as read-only.
This optimizes for reading data and prevents any writes.
If a write is attempted, an error or rollback occurs.
The transaction still opens but disallows data changes.
Use it for methods that only fetch data to improve performance and safety.

Full Transcript

In Spring Boot, marking a method with @Transactional(readOnly = true) starts a transaction flagged as read-only. This means the method can read data but cannot write or change it. When the method runs, the transaction begins with read-only set to true. If the code tries to write data, the transaction will throw an error or roll back to prevent changes. If no writes happen, the transaction commits normally. This helps optimize database access and protects data integrity by ensuring no accidental writes occur during read-only operations.

Practice

1. What is the main purpose of using @Transactional(readOnly = true) in Spring Boot?

easy

A. To allow data modifications within the transaction

B. To optimize performance by indicating the method only reads data

C. To disable transaction management entirely

D. To automatically commit changes after method execution

Solution

1. Step 1: Understand the role of read-only transactions

   Read-only transactions tell Spring the method will only read data, not modify it.

2. Step 2: Recognize performance benefits

   This allows Spring and the database to optimize the transaction for reading, improving performance.

3. Final Answer:

   To optimize performance by indicating the method only reads data -> Option B

4. Quick Check:

   Read-only = optimize read performance [OK]

Hint: Read-only means no data changes allowed, just reading [OK]

Common Mistakes:

• Thinking readOnly=true allows data changes
• Confusing readOnly with disabling transactions
• Assuming it commits changes automatically

2. Which of the following is the correct way to declare a read-only transaction on a method in Spring Boot?

easy

A. @Transactional(readOnly = true)

B. @Transactional(readOnly)

C. @Transactional(enabled = true)

D. @Transactional(readOnly = false)

Solution

1. Step 1: Recall the correct syntax for read-only transactions

   The correct attribute is readOnly = true inside the @Transactional annotation.

2. Step 2: Check each option

   @Transactional(readOnly = true) uses the exact correct syntax. Others are either wrong attribute names or values.

3. Final Answer:

   @Transactional(readOnly = true) -> Option A

4. Quick Check:

   Correct syntax uses readOnly = true [OK]

Hint: Use readOnly = true exactly inside @Transactional [OK]

Common Mistakes:

• Using readOnly without = true
• Using readOnly = false by mistake
• Using non-existent attributes like enabled

3. Consider this Spring Boot method:

@Transactional(readOnly = true)
public List<User> getUsers() {
    userRepository.save(new User("John"));
    return userRepository.findAll();
}

What will happen when this method runs?

medium

A. An exception will be thrown because save is called in a read-only transaction

B. The save call will be ignored, but findAll will return existing users

C. The new user "John" will be saved and returned in the list

D. The method will run normally without any restrictions

Solution

1. Step 1: Understand read-only transaction restrictions

   Read-only transactions prevent data modifications like save or update operations.

2. Step 2: Analyze the method behavior

   Calling save inside a read-only transaction causes Spring or the database to throw an exception.

3. Final Answer:

   An exception will be thrown because save is called in a read-only transaction -> Option A

4. Quick Check:

   Save in read-only transaction = exception [OK]

Hint: Save inside read-only transaction causes error [OK]

Common Mistakes:

• Assuming save silently fails
• Thinking save works normally in read-only
• Ignoring transaction settings

4. You have this method:

@Transactional(readOnly = true)
public void updateUserName(Long id, String name) {
    User user = userRepository.findById(id).orElseThrow();
    user.setName(name);
}

Why might this method fail to update the user's name?

medium

A. Because the method is missing @Transactional annotation

B. Because findById does not return a user

C. Because setName is not a valid method

D. Because readOnly = true prevents any data changes inside the transaction

Solution

1. Step 1: Understand effect of readOnly = true on data changes

   Read-only transactions prevent changes from being saved to the database.

2. Step 2: Analyze the method's update attempt

   Even though the user object is modified, the transaction will not commit changes due to readOnly=true.

3. Final Answer:

   Because readOnly = true prevents any data changes inside the transaction -> Option D

4. Quick Check:

   readOnly = true blocks data updates [OK]

Hint: readOnly = true blocks saving changes [OK]

Common Mistakes:

• Assuming object changes auto-save without commit
• Thinking findById always fails
• Ignoring transaction annotation effects

5. You want to create a service method that fetches user data without risking accidental updates and improves performance. Which approach is best?

hard

A. Do not use any transaction annotation and perform all operations directly

B. Use @Transactional without readOnly and manually avoid updates

C. Annotate the method with @Transactional(readOnly = true) and avoid any save/update calls

D. Use @Transactional(readOnly = false) to allow updates if needed

Solution

1. Step 1: Identify the goal of safe read-only data fetching

   The goal is to read data safely without accidental changes and improve performance.

2. Step 2: Choose the best annotation and practice

   Using @Transactional(readOnly = true) explicitly marks the method as read-only, enabling optimizations and preventing writes.

3. Final Answer:

   Annotate the method with @Transactional(readOnly = true) and avoid any save/update calls -> Option C

4. Quick Check:

   Use readOnly = true for safe, optimized reads [OK]

Hint: Use readOnly = true to prevent accidental writes [OK]

Common Mistakes:

• Skipping readOnly and risking accidental writes
• Not using transactions at all
• Using readOnly = false when no updates needed