Spring Data JPA & Hibernate Mastery Interview Questions

It's the structural mismatch between how Java thinks (objects — nested, referenced, identity-aware) and how a relational database thinks (flat tables, foreign keys only). Three of the five faces: granularity (nested objects vs. flat rows), identity (== reference equality vs. matching primary key values), and associations (direct object references vs. foreign key columns with no built-in navigation).

You can, for genuinely trivial single-table CRUD — but for any real object graph (parent-child relationships, inheritance, deep navigation), hand-written JDBC means manually writing and maintaining the INSERT/SELECT/JOIN mapping code for every entity, and manually reconstructing Java objects from flat rows every time — repetitive, error-prone, and expensive to keep in sync as the schema evolves. ORM automates exactly this translation.

JPA is a specification — a set of interfaces and annotations with no executable logic of its own. Hibernate is one concrete implementation ('provider') of that specification, alongside EclipseLink and OpenJPA. Spring Boot uses Hibernate as its default JPA provider, which is why the two terms are often used loosely as if interchangeable, even though they're structurally distinct.

In principle yes, since application code targets JPA's standard interfaces — but in practice, most non-trivial applications end up relying on at least some provider-specific features (Hibernate-specific annotations, query hints, caching configuration) that fall outside JPA's standard contract, making a real provider switch require reviewing and rewriting those specific pieces, not a true drop-in replacement.

EntityManagerFactory is heavyweight, thread-safe, and created exactly once per application/datasource — it holds expensive parsed mappings and connection pool configuration. EntityManager is lightweight, NOT thread-safe, and created fresh per unit of work. The difference matters because recreating the factory per request is a severe, avoidable performance mistake, and sharing an EntityManager across threads causes real concurrency bugs, since it's explicitly not designed for that.

Spring's @Transactional and dependency injection transparently obtain a fresh, request-scoped EntityManager from the one shared EntityManagerFactory for you, and close it when the transaction completes — this is exactly why most Spring Boot code never directly references EntityManagerFactory at all, even though it's working correctly underneath every repository call.

Hibernate's dirty checking compares a managed entity's current field values against a snapshot taken when it was loaded, at flush time. If any field differs, Hibernate generates an UPDATE for it automatically — the entity is already tracked ('managed') by the persistence context, so no explicit save call is needed to trigger persistence.

A flush executes the pending SQL (INSERTs/UPDATEs/DELETEs) needed to sync the persistence context's state to the database, but doesn't make those changes permanently visible to other transactions — a flushed-but-uncommitted change is still fully rollback-able. A commit is what actually finalizes the transaction, making its effects (already flushed) permanently visible to others.

The persistence context holds every loaded/managed entity (plus its load-time snapshot for dirty checking) for the entire life of the unit of work — processing thousands of entities in one transaction with no cleanup means all of them accumulate in memory simultaneously. The fix is periodically calling flush() followed by clear() to sync pending changes and release the accumulated entities from the persistence context.

merge() does NOT make the object you passed in managed — it copies that object's state onto a different, managed entity (looked up or loaded by ID) and returns THAT object. The object you originally passed in remains detached. Continuing to use the original reference, expecting it to now be managed and dirty-checked, is a very common real bug.

A lazy-loaded association is represented by a Hibernate proxy that fetches its real data on first access — but only while its originating persistence context is still open. If the entity has since become detached (its transaction/request already ended) and code tries to access that uninitialized proxy field, Hibernate has no open session left to fetch the data from, and throws LazyInitializationException.

A transient object was created with `new` and has never been seen by Hibernate at all — it has no persistence identity yet. A detached object WAS previously managed (Hibernate was tracking it, possibly with a real database ID) but its persistence context has since closed, so it's no longer dirty-checked, even though it still holds its data.

It gives you save/findById/findAll/delete plus paging/sorting plus JPA-specific batch operations, all with zero implementation code. At startup, Spring scans for interfaces extending it and generates a dynamic proxy implementing your interface, using EntityManager operations underneath.

Spring Data parses and validates a derived method's name against the entity's actual mapped fields eagerly, when it builds the repository proxy at application startup — not lazily, on first invocation — so a field that doesn't exist is caught immediately rather than causing a runtime failure later.

When a query's conditions are genuinely dynamic at runtime — for example, a search form where the user may supply any combination of optional filters. A fixed derived method name or JPQL string can't express "this condition, but only if it was supplied"; Specifications compose predicates conditionally at runtime.

A native query gives full access to database-specific SQL features JPQL can't express, but sacrifices portability across JPA providers/databases and typically needs explicit result-set mapping back to entities or DTOs, unlike JPQL which maps automatically.

Page executes your paginated query plus a separate COUNT query to report the total number of results. Slice skips that count query entirely, only fetching one extra row to determine whether a next page exists — cheaper, but it can't tell you the total page count.

A projection selects only the specific fields you actually need, skipping full entity hydration (and any lazy associations) entirely — for a list/display view that only shows a few fields, this avoids loading and constructing data the caller never uses.

Single Table (one table, a discriminator column, nullable columns for subtype-specific fields — fastest, no joins, but sparse columns), Joined (one table per subtype joined back to a base table — normalized, but requires a join to reconstruct a full entity), and Table Per Class (each subtype fully independent — no joins for one subtype, but polymorphic queries across all subtypes need a UNION).

IDENTITY relies on the database generating the primary key value at insert time, which means Hibernate must execute each insert individually to get back its generated ID before it can proceed — it can't pre-assign IDs and batch multiple inserts together the way GenerationType.SEQUENCE (with a configured allocationSize) can.

It marks the @OneToMany side as the inverse (non-owning) side, telling Hibernate the foreign key already lives on the other (@ManyToOne) side's table — so Hibernate doesn't create a separate join table for this relationship. Changes must be made (and persisted) via the owning side; mutating only the inverse side's collection without updating the owning side won't persist.

CascadeType.ALL propagates persist/merge/remove from parent to every child automatically — appropriate for genuine "part-of" ownership (an Order's LineItems), but applied broadly and by default, it can cause an accidental cascading delete on a relationship that was never meant to propagate removal, such as deleting a Customer because one of their many Orders was removed.

EAGER — unlike @OneToMany and @ManyToMany, which default to LAZY. This is a common, genuine gotcha: developers who assume every association defaults to lazy loading are surprised to find @ManyToOne/@OneToOne associations loading eagerly on every parent fetch unless explicitly overridden to LAZY.

Calling an @Transactional method from another method within the SAME class bypasses Spring's AOP proxy entirely — it becomes a direct Java method call rather than going through the proxy that actually starts the transaction. The transactional behavior is silently skipped because the proxy, which is what intercepts external calls to the bean, was never invoked.

No — Spring's default rollback rule only triggers automatically for unchecked exceptions (RuntimeException and subclasses). A checked exception requires explicitly configuring rollbackFor = SomeException.class, or the transaction will commit despite the exception being thrown.

REQUIRED (the default) joins an already-active transaction if one exists, or starts a new one if not — a failure anywhere ties back to the same outer transaction. REQUIRES_NEW always suspends any existing transaction and starts a completely independent one with its own commit/rollback, unaffected by the outer transaction's eventual outcome.

Loading N parent entities with one query, then accessing a LAZY association on each one in a loop triggers N additional queries — one per parent — because Hibernate has no way to know ahead of time that the same association will be accessed on every parent in the collection.

The JOIN multiplies result rows — one row per child — so applying a LIMIT/pagination to the raw SQL result doesn't correctly limit the number of DISTINCT parent entities; it can cut off partway through a parent's children or produce an incorrect page size, since the database has no concept that multiple rows belong to the same logical parent.

It eliminates the N+1 pattern for the one access path that triggered it, but now loads that association on EVERY load of the parent entity, everywhere in the application — including code paths that never needed it — trading one performance problem for a different, broader one that's harder to see.

Each application instance holds its own separate copy of the cache — an update on one instance doesn't invalidate another instance's stale cached copy, since there's no shared state between them. A distributed cache like Redis solves this by giving every instance a single shared view.

The query cache invalidates at the table level, not the row level — ANY write to a table involved in a cached query invalidates every cached query result touching that table, regardless of whether the specific rows a given cached query returned were actually affected by that write.

Hibernate includes the loaded version value in the generated UPDATE's WHERE clause and increments it on write. If another transaction already updated (and bumped the version of) the same row, the WHERE clause matches zero rows — Hibernate detects this via the affected-row count and throws OptimisticLockException.

When contention is high and a lost update or a retry storm under load would be genuinely unacceptable — for example, decrementing the last few units of inventory during a flash sale, where many concurrent buyers targeting the same rows would cause excessive optimistic-lock retries. Pessimistic locking makes conflicting transactions wait instead, guaranteeing no conflict happens at all.

Connections being held longer than necessary — most often from a slow, unindexed query or an overly broad transaction boundary (doing non-database work inside a @Transactional method) — rather than the pool simply being undersized for actual concurrent load. Increasing pool size without investigating why connections are held too long only treats the symptom.

It exposes aggregate, queryable counters (total queries executed, second-level cache hit/miss ratio, entity load counts) that can be surfaced on a production monitoring dashboard — giving early warning of a caching regression or a newly introduced N+1 pattern before it becomes a user-facing incident, not just a one-off local debugging tool.

It auto-generates/updates the schema directly from your entity classes with no reviewable history, no data-migration awareness, and it can silently drop columns Hibernate believes are no longer needed. Flyway/Liquibase replace this with versioned, reviewable, ordered SQL migrations that are explicitly tracked and never silently applied.

It's implemented via a Hibernate entity listener (AuditingEntityListener) hooked into the standard JPA lifecycle callbacks (@PrePersist/@PreUpdate) — the same entity lifecycle from earlier in the course — so the timestamp population happens automatically as part of persist/update, with zero manual bookkeeping in application code.

If a database update succeeds but a subsequent, separate network call to notify another service fails (a crash, a network partition), the local data is committed but the other service never finds out — the two systems silently diverge. This is unavoidable with this approach because the database commit and the network call are two entirely separate operations with no shared transactional guarantee.

It writes the event/message to be published into an outbox table in the SAME local database transaction as the actual business data change — since both are just INSERT statements in one transaction, they're genuinely atomic (both succeed or both roll back together). A separate process then reliably publishes the outbox rows afterward, closing the gap a separate network call would have left open.

H2 in PostgreSQL compatibility mode is not the same actual database engine — it doesn't support every PostgreSQL-specific feature (certain functions, JSONB specifics, constraint behaviors), and subtle SQL interpretation differences mean it can silently behave differently than real PostgreSQL for exactly the kind of edge case a test is meant to catch.

It spins up a real, ephemeral Docker container running the actual production database engine (real PostgreSQL, for instance) for the duration of the test run, rather than an in-memory approximation — tests run against genuinely the same engine as production, catching database-specific behavior an embedded database can't.

Read replicas scale read throughput only — every write still goes through the single primary. Sharding splits the data itself across multiple independent database instances, so each shard handles both reads AND writes for its own subset of data, genuinely scaling both dimensions, at a real cost in cross-shard query complexity.

Read replicas serve the SAME schema/model for reads and writes, just on separate instances. CQRS is for when read and write access patterns have genuinely diverged — for example, complex search/filtering reads that need a denormalized, purpose-built shape versus simple, normalized transactional writes — letting each side be optimized independently rather than compromising on one shared schema.

The correct fix is either initializing the needed association before the persistence context closes (JOIN FETCH/Entity Graph for that specific access pattern) or restructuring code to access it while the session is still open. The common wrong fix is making the association globally EAGER, which resolves the one call site's symptom while silently loading that association everywhere else the entity is used, often introducing a new over-fetching or N+1 problem.

Two concurrent requests can both pass the application-level existence check before either one has actually committed its insert — the check-then-insert sequence is inherently racy under real concurrency. The actual fix is relying on and gracefully handling the database-level unique/foreign-key constraint itself, since only the database can atomically enforce uniqueness across concurrent transactions.

Spring Data JDBC has no persistence context at all — no first-level cache, no dirty checking, no lazy loading. Every save() is explicit and immediate, and every load fetches the full aggregate eagerly, every time. Spring Data JPA's entire persistence-context machinery (this course's Chapter 4) simply doesn't exist in Spring Data JDBC.

For a genuinely simple domain model with shallow relationships, JPA's automatic behaviors (dirty checking, lazy loading, cascades) add mental overhead and surprising failure modes (LazyInitializationException, N+1) without much offsetting benefit. Spring Data JDBC trades that automation for a smaller, fully explicit, more predictable model.

In MyBatis, you write the actual SQL statement explicitly (in XML or annotations); MyBatis's job is only to map the result set back to Java objects automatically. In Hibernate, the ORM generates the SQL itself from JPQL or derived queries — you rarely write raw SQL directly.

Compile-time query safety — jOOQ generates a type-safe Java API directly from your actual database schema, so a typo in a column name or an incompatible type is a compile error, not a runtime failure. Neither Hibernate's JPQL nor MyBatis's SQL strings are checked until the query actually runs.

For each loaded row, JPA registers the entity in the persistence context, takes a dirty-checking snapshot, and may generate lazy-loading proxies — real, measurable work, but small relative to actual query execution time and network latency for typical application queries. It only becomes measurable at very high row counts or very high request throughput.

The actual bottleneck in a slow query is far more often a missing index or an N+1 pattern than JPA's entity-hydration overhead — raw JDBC doesn't automatically fix either of those, so rewriting for performance without first measuring risks adding real complexity for a problem that might not have existed, or might not have been the JPA layer at all.

The javax.persistence to jakarta.persistence namespace migration — every @Entity/@Id/@Column import changes package names. It's mechanical for your own code, but any third-party library still referencing the old javax.persistence namespace becomes incompatible until updated, a real practical upgrade blocker some teams hit.

No — the underlying model this entire course covers is unchanged in spirit. What changed are specific APIs (the namespace), the internal query translation engine (a new SQL AST-based approach generating more efficient SQL for many query shapes), and newly-native features like JSON column mapping that previously needed third-party libraries.

Discriminator (shared schema, shared tables, Hibernate auto-injects a tenant filter into every query — cheapest, weakest isolation), schema-based (separate schema per tenant in one database — moderate cost, moderate isolation), and database-based (separate physical database per tenant — highest cost, strongest isolation). The right choice depends on tenant count and isolation/compliance requirements.

Hand-rolled filtering requires every developer to remember to add a tenant_id condition to every single query, forever — one missed query is a cross-tenant data leak. Hibernate's discriminator strategy injects the tenant filter automatically at the SQL generation layer for every query against a multi-tenant-mapped entity, making isolation structural rather than trusted to memory.

@SQLDelete replaces the actual DELETE Hibernate would generate with a custom UPDATE (e.g., setting a deleted_at timestamp), so calling remove() performs a soft delete. @SQLRestriction/@Where automatically appends a filter excluding soft-deleted rows to every query Hibernate generates for that entity. Using only @SQLDelete still requires manually filtering soft-deleted rows in every other query; using only @SQLRestriction doesn't change what remove() actually does.

No — the automatic filter only applies to Hibernate-generated SQL (derived queries, JPQL). A raw native query bypasses it entirely and needs its own explicit exclusion condition if soft-deleted rows shouldn't appear in that query's results.

A bulk update executes as one SQL statement directly against the database, entirely bypassing entity loading and the persistence context. Hibernate has no way to know the bulk update affected a row corresponding to an already-managed entity, so that entity's in-memory field values won't reflect the change unless you explicitly refresh or clear the persistence context afterward.

A bulk update executes ONE SQL statement affecting many rows, entirely skipping entity loading and dirty checking. JDBC batching still executes one statement PER entity, just groups several of them into fewer network round-trips (via hibernate.jdbc.batch_size) — it reduces round-trip count, not the total number of statements the database processes.

It translates directly to a JDBC CallableStatement — the same underlying mechanism raw JDBC would use, just wrapped in JPA's more convenient parameter-registration and result-retrieval API. Unlike JPQL, a stored procedure's logic is never translated or reinterpreted by Hibernate; it runs entirely, opaquely, inside the database.

Because it's still real business logic, just living outside the application's normal codebase — it lives in the database instead. Treating it as an untestable black box because it isn't Java code misses that it needs the same code review, versioning (via migration tools like Flyway/Liquibase), and testing discipline as any other significant logic in the system.

JSONB stores content in a parsed, binary internal representation rather than raw text, which is specifically what allows efficient indexing (a GIN index) and fast containment queries. Plain JSON stores the exact text and must be re-parsed on every access, making indexed querying into its structure far less efficient.

A JSON column gains schema flexibility — new fields can be added without a migration, useful for genuinely variable or evolving data. It loses the relational model's structural guarantees: no database-level enforcement of the JSON's internal shape, and querying/filtering/joining on a nested JSON field is generally more awkward and less broadly indexable than an equivalent relational column.