Atomicity in Database Transactions
Fast recall
Quick revision
Core answer
@Transactional can declare that boundary; rollback follows the configured rules and, by default, RuntimeException and Error cause rollback while checked exceptions do not.Whether the candidate understands atomicity as the all-or-nothing guarantee and can explain rollback behavior in both database and Spring contexts
Confusing atomicity with consistency or isolation, or not understanding that unchecked exceptions automatically trigger rollback in Spring while checked exceptions require explicit configuration
Explain that recovery is engine-specific: some engines use separate undo data, while others combine redo logging, MVCC visibility, and transaction status.
Interview-ready guide
Interview answer
Atomicity means a transaction has one committed outcome: all its database changes commit or none do. A transfer shows it clearly—the debit and credit belong in the same transaction. Storage engines reach that result in different ways, using combinations of transaction status, MVCC, redo logging, and sometimes separate undo logs. In Spring, @Transactional declares the boundary. By default, RuntimeException and Error cause rollback, while a checked exception needs a configured rollback rule. The boundary only covers participating resources, so an email or remote payment call needs idempotency and a recovery pattern rather than an assumed database rollback.
Atomicity in Database Transactions
Direct Answer
Atomicity means a transaction has one committed outcome: all of its changes commit, or none of them have a committed effect. In Spring, @Transactional can declare that boundary; rollback follows the configured rules and, by default, RuntimeException and Error cause rollback while checked exceptions do not.
Code Example
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.math.BigDecimal;
@Service
public class OrderService {
private final OrderRepository orderRepo;
private final InventoryService inventoryService;
public OrderService(OrderRepository orderRepo, InventoryService inventoryService) {
this.orderRepo = orderRepo;
this.inventoryService = inventoryService;
}
@Transactional // Atomicity: all operations or none
public Order placeOrder(Long productId, int quantity) {
var order = new Order(productId, quantity);
orderRepo.save(order); // Inserted into database
inventoryService.reduceStock(productId, quantity); // If this throws exception...
// ...the entire transaction rolls back automatically
// Order insert is undone, database returns to pre-transaction state
return order; // Only reached if both operations succeed
}
}
Common Mistakes & Pitfalls
- Assuming every exception rolls back: Spring rolls back on
RuntimeExceptionandErrorby default; configure checked-exception rules deliberately. - Including remote side effects: A database rollback cannot unsend an email or reverse an HTTP request.
- Misreading self-invocation: A same-object call skips the inner annotation in proxy mode, though an outer transaction may already exist.
Check your understanding
Answer these without looking back at the article.
- How does Spring @Transactional implement atomicity?
- What exceptions trigger a rollback in Spring @Transactional?
- What is the difference between Atomicity and Durability?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.