Read-only transactions in Spring Boot - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a read-only transaction tries to perform a write?

Consider a Spring Boot service method annotated with @Transactional(readOnly = true). What is the expected behavior if this method attempts to save a new entity to the database?

Spring Boot

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class UserService {

    @Transactional(readOnly = true)
    public void createUser(String name) {
        User user = new User();
        user.setName(name);
        userRepository.save(user); // Attempt to write inside read-only transaction
    }
}

A The save operation is ignored and no data is persisted, but no exception is thrown.

B The transaction commits successfully and the new user is saved to the database.

C The transaction silently rolls back without any exception or data change.

D An exception is thrown at runtime indicating that a write operation is not allowed in a read-only transaction.

💡 Hint

Think about how Spring enforces read-only transactions at runtime.

Spring marks the transaction as read-only, and depending on the database and transaction manager, attempting to write inside such a transaction typically causes an exception to prevent data modification.

📝 Syntax

intermediate

Identify the correct way to declare a read-only transaction in Spring Boot

Which of the following method annotations correctly configures a read-only transaction in Spring Boot?

A @Transactional(readonly = true)

B @Transactional(readOnly = true)

C @Transaction(readOnly = true)

D @Transactional(readOnly = "true")

💡 Hint

Pay attention to case sensitivity and annotation spelling.

The correct attribute name is 'readOnly' with capital 'O' and the annotation is '@Transactional'.

❓ state_output

advanced

What is the effect of read-only transactions on Hibernate's session flush?

In a Spring Boot application using Hibernate, what happens to the session flush behavior inside a method annotated with @Transactional(readOnly = true)?

A Hibernate throws an exception if any flush is attempted inside a read-only transaction.

B Hibernate flushes the session normally, committing all changes to the database.

C Hibernate disables automatic session flush, so changes are not synchronized with the database.

D Hibernate flushes only entity deletions but ignores inserts and updates.

💡 Hint

Think about how read-only transactions optimize performance by avoiding unnecessary writes.

In read-only transactions, Hibernate avoids flushing the session to prevent accidental data changes, improving performance.

🔧 Debug

advanced

Why does a read-only transaction still allow data modification in some cases?

A developer marks a service method with @Transactional(readOnly = true) but notices that data is still being updated in the database. What is the most likely cause?

A The underlying database or transaction manager does not enforce read-only transactions, so writes are allowed.

B The <code>readOnly</code> attribute was misspelled, so the annotation was ignored.

C The method is private, so Spring's transaction proxy does not apply the transaction.

D The entity manager is configured to ignore transaction settings.

💡 Hint

Consider how different databases handle read-only flags.

Some databases or transaction managers do not enforce read-only transactions, so writes can still occur despite the annotation.

🧠 Conceptual

expert

Why use read-only transactions in Spring Boot applications?

Which of the following is the best explanation for why developers use @Transactional(readOnly = true) in Spring Boot service methods?

A To optimize performance by avoiding unnecessary database locks and flushes during read operations.

B To automatically rollback any changes made during the transaction.

C To prevent any accidental data reads during write operations.

D To enable caching of all database queries within the transaction.

💡 Hint

Think about how read-only transactions affect database interaction and resource usage.

Read-only transactions help optimize performance by signaling the database and ORM to avoid unnecessary locking and flushing, improving efficiency for read 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