JPA & Hibernate Interview Cheat Sheet

JPA is the specification (annotations, EntityManager, JPQL). Hibernate is the most popular implementation, which maps entities and generates SQL. Spring Data JPA sits on top and generates repository implementations, query methods, paging and auditing.

CrudRepository offers basic CRUD. JpaRepository extends the list-returning CRUD and paging/sorting repositories and adds JPA-specific methods like flush, saveAndFlush, deleteAllInBatch and getReferenceById.

findById hits the database (or the first-level cache) and returns an Optional. getReferenceById returns a lazy proxy without a query — ideal for setting foreign keys; it fails with EntityNotFoundException only when data is accessed.

The persistence context: within one transaction, loading the same entity by id returns the same instance without another query. It's per EntityManager, unlike the optional, shared second-level cache.

At flush, Hibernate compares managed entities with their loaded snapshots and issues UPDATEs for changes — so modifying a managed entity in a transaction is enough.

One query loads N parents, then each lazy association access runs another query. Solve it with JOIN FETCH, @EntityGraph, @BatchSize/default_batch_fetch_size, or DTO projections.

It loads associations on every query, can't be overridden per query, and causes extra selects (N+1) for JPQL queries. Use LAZY and fetch per use case.

Accessing an uninitialised lazy association after the persistence context closed. Fetch the data inside the transaction or return DTOs.

It marks the inverse side of a bidirectional relationship and names the owning field. Only the owning side's changes update the foreign key.

REQUIRED joins the current transaction (or starts one). REQUIRES_NEW suspends it and runs a separate transaction that commits or rolls back independently.

On checked exceptions (by default), when exceptions are caught inside the method, and when the method is called via self-invocation or isn't proxied.

Optimistic: a @Version column is checked on update; conflicts throw and you retry — best for low contention. Pessimistic: SELECT … FOR UPDATE locks the row so others wait — best for hot rows.

SINGLE_TABLE by default, for speed and simple polymorphic queries. JOINED when subclasses have many fields or need NOT NULL constraints. @MappedSuperclass when you only share fields and never query the base type. Avoid TABLE_PER_CLASS.

The first-level cache is per persistence context and always on. The second-level cache is shared across transactions, opt-in, and serves lookups by id. Use it for read-mostly reference data.

With versioned Flyway or Liquibase migrations applied at deployment, ddl-auto=validate, and expand-and-contract steps so old and new application versions both work during a rollout.

With @DataJpaTest against the real database engine via Testcontainers, flushing so the SQL actually runs and clearing so reads hit the database. Critical flows are tested without a test-level transaction, and query counts are asserted to catch N+1.

Look at the pool metrics (active, pending) and turn on leak detection. Look for long transactions (remote calls inside @Transactional), Open Session in View, nested REQUIRES_NEW calls and slow queries. Fix those before making the pool bigger.

Soft deletes with @SoftDelete (or @SQLDelete + @SQLRestriction), unique constraints that account for the deleted flag, and Envers if you need the full change history.

Turn on SQL logging, identify the lazy associations being touched (often during JSON serialization), then fetch them with JOIN FETCH/@EntityGraph or return a DTO projection; enable default_batch_fetch_size as a safety net and consider disabling OSIV.

Use @Version optimistic locking (one update fails → retry or show "sold out"), a pessimistic FOR UPDATE lock on the seat row, or an atomic conditional update (UPDATE … SET available = false WHERE id = ? AND available = true, check 1 row updated), backed by a unique constraint.

IDENTITY ids disable JDBC batching, every entity stays in the persistence context (dirty checking grows), and each insert is a round trip. Use SEQUENCE ids, hibernate.jdbc.batch_size, order_inserts, flush and clear every N rows — or use JdbcTemplate.batchUpdate / database bulk-load tools.

Bulk queries bypass the persistence context, so the already-loaded entity is stale. Use @Modifying(clearAutomatically = true, flushAutomatically = true) or refresh the entity.

Fetch-joining a collection with pagination makes Hibernate load every row and paginate in memory (HHH90003004). Paginate parent ids first, then fetch their collections, or use batch fetching.

Write it in a separate bean method with @Transactional(propagation = REQUIRES_NEW) — it commits independently of the outer transaction.