Data Access and Transactions
Cert Focus
You should know Spring Data repository basics, JPA relationships, transaction boundaries, and common performance traps.
Must Know
- Spring Data JPA creates repository implementations at runtime.
- Query methods are derived from method names.
@Transactionalis proxy-based in typical Spring applications.- Transactions usually belong on service methods.
- Rollback defaults apply to unchecked exceptions.
- Entity relationships affect SQL behavior and loading.
- Lazy loading, N+1 queries, and transaction boundaries matter.
Direct Book Links
- Spring Data JPA Mental Model
- Repository Query Methods
- Transactions Deep Dive
- Entity Relationships
- JPA Performance and Best Practices
Exam Trap
Self-invocation can bypass transactional proxies, so a method inside the same class calling another @Transactional method may not start a new transactional behavior.
Self-Check
- Can I explain what Spring Data repositories generate?
- Can I explain why transactions usually belong on services?
- Can I explain rollback defaults?
- Can I explain lazy loading and N+1 in simple terms?
Model Answers
Spring Data repositories generate runtime implementations for repository interfaces, including common CRUD operations and query methods.
Transactions usually belong on services because service methods represent business use cases and define clear transaction boundaries.
By default, Spring rolls back transactions for unchecked exceptions and errors. Checked exceptions do not trigger rollback unless configured.
Lazy loading means related data is loaded later when accessed. N+1 happens when one query loads parent records and then one additional query runs for each related record.
Memory Sentence
Repositories handle persistence access; services usually own transaction boundaries.