Spring Data JPA & Transactions

Spring Data parses a repository method's name and generates the query implementation automatically — no SQL or JPQL written at all, as long as the method follows the naming convention.

interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByLastName(String lastName);
    List<User> findByAgeGreaterThanAndActiveTrue(int age);
    Optional<User> findByEmailIgnoreCase(String email);
    long countByCity(String city);
}

Great for simple lookups; once conditions get complex (multiple joins, dynamic filters), an explicit @Query or the Criteria API reads far more clearly than an increasingly long method name.

@Query lets you write the query explicitly instead of relying on method-name derivation — needed once a query gets complex, or needs a join/aggregation the naming convention can't express.

• JPQL (the default) is written against your entity model (class and field names, not table/column names) — portable across databases, and Hibernate translates it to the right SQL dialect.
• Native SQL (nativeQuery = true) is real, database-specific SQL — an escape hatch for vendor-specific features (window functions, full-text search) JPQL can't express, at the cost of database portability.

@Query("SELECT u FROM User u WHERE u.active = true AND u.age > :minAge")
List<User> findActiveAdults(@Param("minAge") int minAge); // JPQL -- entity/field names

@Query(value = "SELECT * FROM users WHERE active = true", nativeQuery = true)
List<User> findActiveNative(); // real SQL -- table/column names

@Entity
class Department {
    @OneToMany(mappedBy = "department") // "department" = the field name on Employee
    List<Employee> employees;
}

@Entity
class Employee {
    @ManyToOne
    @JoinColumn(name = "department_id") // this side owns the foreign key column
    Department department;
}

mappedBy marks the inverse (non-owning) side of a bidirectional relationship — it just tells JPA "the foreign key is managed by the other side's field," so JPA doesn't try to create a redundant join table. The side without mappedBy (here, Employee) owns the actual foreign-key column. @ManyToMany works similarly but needs a join table (@JoinTable) on the owning side, since neither entity can hold the other's foreign key directly for a many-to-many relationship.

Add a Pageable (and/or Sort) parameter to a repository method — Spring Data JPA translates it into the right LIMIT/OFFSET/ORDER BY automatically, and returns a Page<T> that also carries total element/page counts.

interface UserRepository extends JpaRepository<User, Long> {
    Page<User> findByActive(boolean active, Pageable pageable);
}

// Usage:
Pageable pageable = PageRequest.of(0, 20, Sort.by("lastName").ascending());
Page<User> page = userRepo.findByActive(true, pageable);
page.getContent();       // the 20 users on this page
page.getTotalElements(); // total matching rows across all pages

Both prevent two transactions from silently clobbering each other's changes to the same row, but with opposite trade-offs:

• Optimistic locking — assumes conflicts are rare. Add a @Version field to the entity; every update checks the version hasn't changed since it was read, and increments it. If another transaction updated the row in between, the version check fails and JPA throws OptimisticLockException — the app then retries or surfaces a "someone else already changed this" error. No database locks are held while the user is "thinking."
• Pessimistic locking — assumes conflicts are likely, so it locks the row upfront (SELECT ... FOR UPDATE, via @Lock(LockModeType.PESSIMISTIC_WRITE)) for the duration of the transaction, blocking any other transaction that tries to read/write that row until the first one commits or rolls back.

@Entity
class Product {
    @Id Long id;
    int stock;
    @Version
    long version; // JPA manages this automatically -- checked and incremented on every update
}

Optimistic locking scales better under low contention (no held locks); pessimistic locking is safer under high contention where retries would be constant, at the cost of reduced concurrency while the lock is held.