Spring Data JPA for Interviews

Master lazy vs eager loading, diagnose the N+1 problem, and fix it using JOIN FETCH — fetch strategy questions are among the most asked in Spring Data JPA interviews.

• Lazy vs Eager loading: default fetch types for @ManyToOne (EAGER) and @OneToMany (LAZY)

• The N+1 problem: 1 query for parents + N queries for children when looping lazy collections

• Fetch joins: using JOIN FETCH in JPQL to load associations in a single query

• Entity Graphs: @EntityGraph annotation as an alternative to JOIN FETCH for dynamic fetching

• FetchType.EAGER pitfall: loading entire object graphs into memory for every query

• LazyInitializationException: accessing a lazy collection outside an open Hibernate session

• Open Session in View: pattern that keeps the session open during the view layer

• DTO projection: initializing required data within service boundaries to avoid lazy loading issues

• Batch fetching: Hibernate optimization to load lazy collections in batches instead of one by one

• When to use EAGER: small, always-needed associations; never for large collections

Define correct ownership, cascade behavior, and orphan removal for all JPA association types — relationship mapping questions test depth of ORM understanding in every interview.

• Association types: @OneToOne, @OneToMany, @ManyToOne, and @ManyToMany mappings

• Relationship ownership: the entity with @JoinColumn is the owner of the relationship

• mappedBy attribute: placed on the non-owning side to reference the owning field

• CascadeType options: PERSIST, MERGE, REMOVE, REFRESH, DETACH, and ALL

• Orphan removal: orphanRemoval=true automatically deletes child entities removed from parent collection

• Cascade vs orphanRemoval: cascade propagates operations, orphanRemoval deletes unlinked children

• @JoinColumn: specifies the foreign key column name in the owning entity's table

• @JoinTable: used for @ManyToMany to define the intermediate join table

• Bidirectional relationships: must keep both sides in sync manually in the entity code

• @Embeddable and @Embedded: mapping value objects as part of an entity without a separate table

Use Spring Data's repository hierarchy, write derived query methods, and execute custom JPQL and native queries — repositories are the most practical topic in JPA interviews.

• Repository hierarchy: CrudRepository → PagingAndSortingRepository → JpaRepository

• CrudRepository: provides basic CRUD operations (save, findById, delete, findAll)

• JpaRepository: extends PagingAndSortingRepository and adds flush, deleteInBatch, and getOne

• Derived query methods: Spring generates queries from method names (findByEmailAndStatus)

• @Query annotation: write custom JPQL or native SQL directly on repository methods

• @Modifying annotation: required for @Query methods that perform UPDATE or DELETE operations

• nativeQuery=true: executes raw SQL instead of JPQL when set on @Query

• Pagination: Pageable parameter returns Page<T> with content, total pages, and total elements

• Sorting: Sort parameter or method name keywords (findAllByOrderByCreatedAtDesc)

• @Param annotation: binds named parameters in @Query expressions to method arguments

Understand the four entity states and how the Persistence Context manages them — entity lifecycle questions reveal whether candidates truly understand how Hibernate works under the hood.

• Transient state: entity created with new keyword, not yet associated with any persistence context

• Managed (Persistent) state: entity is tracked by the current Hibernate session

• Detached state: entity was managed but the session was closed or entity was evicted

• Removed state: entity is scheduled for deletion when the transaction commits

• EntityManager persist(): moves transient entity to managed state

• EntityManager merge(): reattaches a detached entity and returns a new managed instance

• EntityManager remove(): moves managed entity to removed state

• Persistence Context: first-level cache that tracks all managed entities within a session

• Dirty checking: Hibernate automatically detects changes to managed entities and flushes them

• Lifecycle callbacks: @PrePersist, @PostLoad, @PreUpdate, @PreRemove for auditing and logic

Apply @Transactional propagation behaviors and isolation levels correctly — transaction management is where senior JPA interviews are won or lost.

• @Transactional: applies proxy-based transaction management to service methods

• Default rollback behavior: rolls back automatically on RuntimeException, not on checked exceptions

• readOnly=true: hints to Hibernate to skip dirty checking and optimize read performance

• Propagation.REQUIRED: joins existing transaction or creates a new one (default behavior)

• Propagation.REQUIRES_NEW: always creates a new transaction, suspending the existing one

• Propagation.MANDATORY: must run within an existing transaction or throws exception

• REQUIRES_NEW caveat: inner transaction failure can still cause outer rollback if exception propagates

• Isolation.READ_COMMITTED: prevents dirty reads, allows non-repeatable reads

• Isolation.REPEATABLE_READ: prevents dirty and non-repeatable reads, allows phantom reads

• Isolation.SERIALIZABLE: prevents all concurrency anomalies but has the lowest performance