Spring Data JPA

@EntityGraph is an annotation you put on a repository method to tell JPA which associations to load eagerly in one query. It fixes the N+1 select problem where each parent triggers an extra query for its children.

Optimistic locking detects concurrent edits without locking rows. You add a @Version field; Hibernate checks it in the UPDATE's WHERE clause and throws an error if another transaction already changed the row.

@Query lets you write your own query on a repository method instead of relying on the method name. By default it's JPQL. You bind values with named parameters like :name using @Param, or by position with ?1.

JpaRepository is the JPA-specific top interface you extend to get ready-made CRUD, paging and sorting methods for an entity, without writing any implementation — Spring generates one at runtime.

A Specification is a reusable object holding one query condition (a WHERE predicate). To use it, your repository extends JpaSpecificationExecutor, which adds methods like findAll(Specification) that run those conditions.

Set nativeQuery=true on @Query and write real database SQL using table and column names instead of entity fields. It's useful for database-specific features JPQL can't express, but the query is not validated at startup and is less portable.

save() stages the change in the persistence context; the SQL may run later. saveAndFlush() saves and immediately runs flush(), forcing the INSERT/UPDATE to the database now — still inside the transaction, not a commit.

Each small Specification is one condition. Combine them with spec1.and(spec2), spec1.or(spec2), and Specification.not(spec). You start from a neutral base and conditionally chain filters that are active, producing one combined WHERE clause.

Fetching two List collections at once throws MultipleBagFetchException. Paginating (Pageable) while join-fetching a collection makes Hibernate load all rows and page in memory (HHH000104 warning). Fix: fetch one collection, use Set for bags, or split into a two-step id-then-fetch query.

A repository method can return Stream<T> to read rows lazily one at a time instead of loading them all. You must run it inside an open transaction and close the stream (try-with-resources), because it keeps a database cursor open.

@Modifying marks a @Query as an UPDATE or DELETE (or INSERT native) rather than a SELECT, so Spring calls executeUpdate() and returns the affected-row count. clearAutomatically clears the persistence context after the query so stale cached entities don't hide the change; flushAutomatically flushes pending changes before it runs.

Add a method to your repository and annotate it with @Procedure, giving the stored procedure's name. Spring Data JPA calls that procedure in the database and maps the result to the method's return type.

Distinct adds SELECT DISTINCT to remove duplicate rows. First and Top limit how many rows come back: findFirstByOrderByScoreDesc returns one row; findTop10By... returns ten. First and Top are interchangeable.

You can navigate into related entities by camel-casing the path: findByAddressCity reaches the City field of the Address association (a JOIN). If a property name is ambiguous, an underscore (findByAddress_City) tells Spring exactly where to split the path.

Ad-hoc: @EntityGraph(attributePaths = {"orders", "orders.items"}) directly on the method. Named: define @NamedEntityGraph on the entity, then reference it with @EntityGraph(value = "..."). Dot notation like "orders.items" fetches nested levels.

Put @Lock(LockModeType.PESSIMISTIC_WRITE) on the repository query method. PESSIMISTIC_READ is a shared lock (others can read, not write); PESSIMISTIC_WRITE is an exclusive lock (SELECT ... FOR UPDATE) that blocks other writers and lockers.

@QueryHints attaches JPA/Hibernate query hints to a repository query — like JDBC fetch size, marking results read-only, or enabling the query cache. It tunes how the query executes without changing what it returns.

Named parameters (:name with @Param) are readable and refactor-safe; positional parameters (?1, ?2) are terser but tied to argument order. Both are bound safely by the driver, which prevents injection. Never concatenate user input into the query string.

getReferenceById returns a lazy proxy without querying the database; it only loads when you access a real property. findById runs a SELECT immediately and returns an Optional with the fully loaded entity (or empty).

Write static methods returning Specification<T>. Each checks its input: if the filter value is null, return a lambda whose toPredicate returns null (no restriction); otherwise build the predicate. Compose the active ones with and().

existsBy returns a boolean (efficient existence check), countBy returns a long count, and deleteBy/removeBy delete matching rows. Derived deletes are modifying queries, so they must run inside a transaction (@Transactional).

FETCH (the default) makes listed attributes EAGER and treats everything not listed as LAZY. LOAD makes listed attributes EAGER but leaves unlisted attributes with their mapped fetch type. FETCH gives a stricter, fully-specified plan.

OPTIMISTIC forces a version check at commit even if you only read the entity (guarding against concurrent changes). OPTIMISTIC_FORCE_INCREMENT additionally bumps the entity's @Version even when the entity itself wasn't modified — useful to signal an aggregate changed.

Pessimistic locks block other transactions, so you risk long waits, deadlocks, and throughput loss. Mitigate with a jakarta.persistence.lock.timeout query hint, consistent lock ordering, short transactions, and never holding a lock across a user round-trip.

deleteAll loads each entity and deletes it one-by-one, running JPA lifecycle callbacks and cascades. deleteAllInBatch issues a single bulk 'DELETE FROM entity' JPQL, bypassing the persistence context, cascades, @PreRemove callbacks, and the first-level cache.

Inside toPredicate, call root.join("association") to reach the related entity, then build a predicate on it. A to-many join can duplicate parents, so add query.distinct(true). Use a fetch join or entity graph to avoid N+1 loading.

Derived methods can only express what fits in a method name: fixed conditions, static sort, and a fixed First/Top limit. Anything needing projections, LEFT joins, subqueries, computed expressions, offset paging, or dynamic optional filters must move to @Query, Pageable, or Specifications/Criteria.

Use @EntityGraph for a declarative eager plan on derived/named repository methods without writing JPQL. Use JOIN FETCH when you already write custom JPQL. Use @BatchSize when you page collections or fetch several to-many sides. Use DTO projections when you only need a few fields read-only.

Use optimistic (@Version) by default — no locks, scales, retry rare conflicts. Use pessimistic (@Lock FOR UPDATE) only for hot, high-contention rows where retries would storm. Handle failures by catching the specific Spring exception and retrying with backoff or reporting a conflict.