Spring Data JPA

What is Spring Data JPA? Three Layers, Not One

This name hides three separate technologies, and confusing them is the single most common source of "wait, is this a JPA thing or a Hibernate thing" confusion:

Without this abstraction, even a simple find-by-email requires manually building a CriteriaQuery or JPQL string against an EntityManager, injected and managed by hand. Spring Data JPA replaces all of that with an interface:

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmail(String email);
    // No implementation anywhere in your codebase. Spring generates one at startup.
}

Setup

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

<dependency>  <!-- runtime driver: H2 for dev, real driver for prod -->
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <scope>runtime</scope>
</dependency>

# application.properties
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.jpa.hibernate.ddl-auto=validate   # never create/update in production — see note below
spring.jpa.show-sql=true

Entity Mapping

import jakarta.persistence.*;

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, length = 100)
    private String name;

    @Column(unique = true, nullable = false)
    private String email;

    @Enumerated(EnumType.STRING)  // ALWAYS STRING — ORDINAL breaks silently if the enum is ever reordered
    private Status status = Status.ACTIVE;

    @OneToMany(mappedBy = "user", cascade = CascadeType.ALL)
    private List<Order> orders = new ArrayList<>();  // LAZY by default

    @ManyToOne
    @JoinColumn(name = "department_id")
    private Department department;  // EAGER by default — see note below

    @PrePersist
    protected void onCreate() { createdAt = LocalDateTime.now(); }

    // constructors, getters, setters
}

Repository Interfaces — Who Actually Implements Them?

/*
 * Repository<T, ID>                    ← marker interface, no methods
 *        ↑
 * CrudRepository<T, ID>                ← save, findById, findAll, deleteById...
 *        ↑
 * PagingAndSortingRepository<T, ID>    ← findAll(Pageable), findAll(Sort)
 *        ↑
 * JpaRepository<T, ID>                 ← flush(), saveAndFlush(), batch deletes
 */

public interface UserRepository extends JpaRepository<User, Long> {
    // You write zero implementation. Ever.
}

Query Derivation — Queries From Method Names

Spring Data parses the method name itself into a query. The keywords compose:

Custom Queries with @Query

public interface UserRepository extends JpaRepository<User, Long> {

    // JPQL — portable across databases, always prefer this over native SQL
    @Query("SELECT u FROM User u WHERE u.email = :email")
    Optional<User> findByEmailAddress(@Param("email") String email);

    // Native SQL — only when JPQL genuinely can't express it (DB-specific functions, hints)
    @Query(value = "SELECT * FROM users WHERE email = :email", nativeQuery = true)
    Optional<User> findByEmailNative(@Param("email") String email);

    // Bulk update/delete — @Modifying is mandatory, or Spring throws at runtime
    @Modifying(clearAutomatically = true)  // clears the persistence context — see note below
    @Query("UPDATE User u SET u.status = :status WHERE u.id = :id")
    int updateStatus(@Param("id") Long id, @Param("status") Status status);
}

Projections — Interface-Based and Record-Based DTOs

// Interface projection — Spring Data generates a proxy matching these getters
public interface UserSummary {
    String getName();
    String getEmail();
}

// Record (DTO) projection — Java 17+ idiom, matches constructor params to entity
// property names. No @Query needed even for a derived query method.
public record UserView(String name, String email) {}

public interface UserRepository extends JpaRepository<User, Long> {
    List<UserSummary> findByStatus(Status status);  // interface projection
    List<UserView>    findByStatusOrderByName(Status status);  // record projection
}

The N+1 Query Problem

This is the single most common Spring Data JPA performance bug in production, and it's invisible in development with a handful of test rows.

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findAll();  // inherited — 1 query
}

for (User user : userRepository.findAll()) {    // query #1: SELECT * FROM users        (1 query)
    user.getOrders().size();                    // orders is LAZY — triggers a query PER user
}                                                // query #2..#N+1: SELECT * FROM orders WHERE user_id = ?  (N queries)

// 1 query to fetch 100 users + 100 separate queries to fetch each user's orders = 101 total

The name literally describes the bug: 1 query to fetch the parent rows, plus N queries — one per row — to lazily fetch each one's associations. It scales linearly with dataset size, which is why it's invisible with 5 test users and catastrophic with 50,000 production users.

Fix 1: JOIN FETCH — one query instead of N+1

@Query("SELECT u FROM User u LEFT JOIN FETCH u.orders WHERE u.status = :status")
List<User> findWithOrdersByStatus(@Param("status") Status status);
// Single query: users LEFT JOIN orders — the association is populated immediately, no follow-up queries

Fix 2: @EntityGraph — same result, without hand-writing JPQL

@EntityGraph(attributePaths = {"orders", "department"})
List<User> findByStatus(Status status);
// Works with a plain derived query method — no @Query needed. Declaratively lists
// which lazy associations to eagerly fetch, for THIS query only.

Transactions and the Service Layer

Every inherited repository method (save, findById, deleteById) is already individually transactional — SimpleJpaRepository is annotated @Transactional internally. Putting @Transactional on the Service layer isn't about adding transactionality that's missing — it's about widening the boundary so multiple repository calls commit or roll back together, as one atomic unit:

@Service
public class OrderService {
    private final OrderRepository orderRepository;
    private final InventoryRepository inventoryRepository;

    public OrderService(OrderRepository orderRepository, InventoryRepository inventoryRepository) {
        this.orderRepository = orderRepository;
        this.inventoryRepository = inventoryRepository;
    }

    @Transactional  // BOTH writes commit together, or BOTH roll back
    public void placeOrder(Order order) {
        orderRepository.save(order);
        inventoryRepository.decrementStock(order.getProductId(), order.getQuantity());
        // if decrementStock throws, the order save above is rolled back too — without
        // @Transactional here, the order would already be permanently committed
    }

    @Transactional(readOnly = true)  // read-only hint: Hibernate skips dirty-checking, may reduce lock overhead
    public List<Order> findRecentOrders() {
        return orderRepository.findTop50ByOrderByCreatedAtDesc();
    }
}

Lazy Loading, LazyInitializationException, and Open Session in View

A LAZY association isn't loaded when the entity is fetched — it's a proxy that fetches on first access. Access it after the persistence session that loaded the entity has closed, and Hibernate can't run the follow-up query:

@Transactional
public User findUser(Long id) {
    return userRepository.findById(id).orElseThrow();  // session open, method returns fine
}
// ... later, in the controller, outside any transaction:
user.getOrders().size();  // throws LazyInitializationException — session is already closed

Pagination and Sorting

public interface UserRepository extends JpaRepository<User, Long> {
    Page<User>  findByStatus(Status status, Pageable pageable);   // includes a COUNT(*) query for total pages
    Slice<User> findByNameContaining(String name, Pageable pageable);  // no COUNT query — cheaper
}

Pageable pageable = PageRequest.of(0, 20, Sort.by("name").ascending());
Page<User> result = userRepository.findByStatus(Status.ACTIVE, pageable);

Specifications — Composable Dynamic Queries

public interface UserRepository extends JpaRepository<User, Long>,
                                       JpaSpecificationExecutor<User> {}

public class UserSpecifications {
    public static Specification<User> hasStatus(Status status) {
        return (root, query, cb) -> cb.equal(root.get("status"), status);
    }
    public static Specification<User> nameLike(String name) {
        return (root, query, cb) -> cb.like(cb.lower(root.get("name")), "%" + name.toLowerCase() + "%");
    }
}

// Compose conditionally — only the filters actually provided end up in the query
Specification<User> spec = Specification.where(null);
if (criteria.status() != null) spec = spec.and(UserSpecifications.hasStatus(criteria.status()));
if (criteria.name()   != null) spec = spec.and(UserSpecifications.nameLike(criteria.name()));
List<User> results = userRepository.findAll(spec);

Auditing

@Configuration
@EnableJpaAuditing
public class JpaConfig {}

@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class Auditable {
    @CreatedDate  @Column(updatable = false)
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;

    @CreatedBy  @Column(updatable = false)
    private String createdBy;

    @LastModifiedBy
    private String updatedBy;
}

@Entity
public class User extends Auditable { /* id + own fields */ }

// Supplies the value for @CreatedBy / @LastModifiedBy
@Component
public class AuditorAwareImpl implements AuditorAware<String> {
    @Override
    public Optional<String> getCurrentAuditor() {
        return Optional.ofNullable(SecurityContextHolder.getContext().getAuthentication())
            .filter(Authentication::isAuthenticated)
            .map(Authentication::getName);
    }
}

Testing the Repository Layer: @DataJpaTest

@DataJpaTest  // loads ONLY JPA config + repositories — no web layer, no full context
class UserRepositoryTest {

    @Autowired private UserRepository userRepository;
    @Autowired private TestEntityManager entityManager;  // direct EntityManager access for test setup

    @Test
    void findByEmail_returnsMatchingUser() {
        entityManager.persist(new User("Ana", "ana@example.com"));
        entityManager.flush();

        Optional<User> found = userRepository.findByEmail("ana@example.com");

        assertThat(found).isPresent();
    }
}

Interview Questions