Hibernate & JPA Internals

The change is written to the database at flush/commit. A managed entity is tracked by the persistence context, and at flush Hibernate compares its current state with the snapshot taken at load time (dirty checking) and issues an UPDATE.

• save() on a managed entity is effectively a no-op for updates.
• Without a surrounding transaction (and with open-in-view only), the entity is still managed for the request, but nothing flushes it, so the change is silently lost.

Yes. With FlushModeType.AUTO (default), Hibernate flushes pending changes before executing a JPQL/HQL query whose query space overlaps the dirty entities, so the query sees them inside the same transaction.

• Native SQL queries: Hibernate 6 flushes only when it can determine affected tables; with JPA-bootstrapped sessions native queries trigger a full flush, but with plain Hibernate API they may not. Add addSynchronizedQuerySpace or call flush() explicitly if in doubt.
• With FlushMode.COMMIT the query would not see the change.

SimpleJpaRepository.save calls entityInformation.isNew(entity). With a wrapper-type @Version field, new means version is null, so persist is chosen; with no version, new means ID is null. If neither indicates new, it calls merge.

• Assigned IDs (e.g. UUID set by the app) and no @Version: isNew is false, so merge runs, issuing an extra SELECT before the INSERT.
• Fix: add a @Version Long version field, or implement Persistable<ID> with a transient isNew flag.
• A primitive long version is never null, so Spring checks it differently (new if 0 in some versions), which is error-prone; use the wrapper type.

No. merge copies the state of the detached instance onto a managed instance (loaded or created) and returns that managed instance; the original argument stays detached. Later changes must be made on the returned object.

Order managed = em.merge(detached);
managed.setStatus(PAID);   // tracked
detached.setStatus(SHIPPED); // ignored

• Merge overwrites all persistent fields, including nulls, so a partial DTO mapped onto a fresh entity can wipe columns.
• Cascade MERGE propagates to associations; missing cascade means detached children are merged only by reference (ID).

One SELECT. The persistence context (first-level cache) holds one managed instance per entity identity (type + ID), so the second find returns the same Java object and == is true.

• Scope is the EntityManager/transaction; a new transaction gets a new context.
• JPQL queries still hit the database but, when rows map to already managed entities, return the existing instances and ignore fresher column values.

The persistence context keeps every loaded entity plus its snapshot until the session closes. Process in chunks, flushing and clearing between chunks, or avoid entities (DTO projection, JDBC, StatelessSession).

for (int i = 0; i < ids.size(); i++) {
    process(em.find(Item.class, ids.get(i)));
    if (i % 100 == 99) { em.flush(); em.clear(); }
}

• Prefer paging by keyset (where id > :last order by id limit :n) with one transaction per chunk.
• Use read-only queries (@QueryHints(READ_ONLY)) to skip snapshots.

With IDENTITY the ID exists only after the INSERT executes, so Hibernate must run each insert immediately to learn the ID and cannot defer and batch them.

• Use SEQUENCE with a pooled optimizer and allocationSize matching the DB sequence INCREMENT BY, so one sequence call serves ~50 inserts.
• Enable batching: spring.jpa.properties.hibernate.jdbc.batch_size=50, order_inserts=true, order_updates=true.
• MySQL has no sequences; options are a table generator (poor concurrency), app-generated UUID/ULID, or accept no insert batching.

Typical causes: IDENTITY generator; entities of different types interleaved (cascade) without order_inserts=true; periodic flush() after every save; saveAll on entities that are not new (merge does SELECT first); logging misleading you.

• The SQL log (show_sql) prints statements pre-batch; verify batching with a datasource proxy (datasource-proxy, p6spy) or compare Statistics#getPrepareStatementCount with the entity insert count when hibernate.generate_statistics is on.
• Version column with optimistic locking prevents batching of updates only on old Hibernate versions without batch_versioned_data (default true since 5).

Never base them on a generated ID that is null before persist, since the hash changes after persist and breaks HashSet membership. Use a business key if one is immutable, otherwise a constant hashCode plus ID-based equals that handles proxies.

@Override public boolean equals(Object o) {
    if (this == o) return true;
    if (!(o instanceof Customer other)) return false;
    return id != null && id.equals(other.getId());
}
@Override public int hashCode() { return getClass().hashCode(); }

• instanceof (not getClass()) because lazy proxies are subclasses; use getters, not fields, on other.
• Constant hashCode is O(n) in huge sets but safe; assigned UUID at construction avoids the problem entirely.
• Lombok @Data on entities pulls in all fields including lazy collections and causes loading or recursion.

Hibernate writes the FK from the owning side, the side without mappedBy (the @ManyToOne). If you only add the child to the parent's collection and never set child.setParent(parent), the FK stays null.

• Keep both sides in sync with helper methods addChild/removeChild.
• Unidirectional @OneToMany with @JoinColumn works, but issues extra UPDATE statements; without @JoinColumn it creates a join table.

Removing from the collection only unlinks them. With orphanRemoval = true on the @OneToMany, Hibernate deletes the child row when it is removed from the collection (or when the parent is deleted). Otherwise the FK is nulled (if nullable and owning) or nothing happens for mappedBy side.

@OneToMany(mappedBy = "parent", cascade = ALL, orphanRemoval = true)
private List<Child> children = new ArrayList<>();

• Never replace the collection instance (setChildren(newList)) on a managed entity with orphanRemoval; Hibernate throws "A collection with cascade=all-delete-orphan was no longer referenced". Clear and add to the existing collection.

CascadeType.REMOVE/ALL on @ManyToMany deletes the other side, which is shared (deleting a Student deletes Courses other students attend, or fails on FK). Use only PERSIST/MERGE if at all.

• Use Set, not List: removing from a List of a bag-mapped many-to-many deletes all join rows and re-inserts the rest.
• If the link needs attributes (enrolled date, grade), model an explicit join entity with two @ManyToOne (and an @EmbeddedId or surrogate key).

Polymorphic queries on TABLE_PER_CLASS use UNION ALL across all subclass tables, and IDENTITY generation is not allowed. It is rarely the right choice.

• SINGLE_TABLE (default): one table plus discriminator; fastest queries, but subclass columns must be nullable and the table grows wide.
• JOINED: normalized, NOT NULL constraints possible, but each query joins the hierarchy.
• @MappedSuperclass: sharing fields only, no polymorphic queries or associations to the parent.

Add @Version (Long/Integer/Instant). Hibernate appends WHERE id=? AND version=? to updates and increments the version; zero rows updated means a concurrent change and an OptimisticLockException (Spring translates it to ObjectOptimisticLockingFailureException).

• In REST, round-trip the version in the DTO/ETag so a stale client is rejected, otherwise the version read at load time in the new request makes the check useless.
• Handle the failure by retrying (@Retryable, new transaction) or returning HTTP 409.
• Bulk JPQL updates bypass the version unless update versioned.

Use it for high-contention rows where retries are costly (inventory decrement, balance transfer). Hibernate issues SELECT ... FOR UPDATE; other transactions locking or updating the row block until commit, or until the lock timeout.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@QueryHints(@QueryHint(name = "jakarta.persistence.lock.timeout", value = "3000"))
Optional<Account> findById(Long id);

• Always lock in a consistent order to avoid deadlocks (e.g. ascending ID).
• SKIP LOCKED (-2 timeout hint) suits job-queue tables.
• Keep transactions short; locks are held until commit.

Plain @Version increments only when the entity's own columns change. If the invariant spans an aggregate (adding an OrderLine should conflict with a concurrent change to the Order), lock the root with OPTIMISTIC_FORCE_INCREMENT so its version is bumped whenever a child changes.

• OPTIMISTIC (read lock) only checks the version at commit without incrementing, protecting against read-then-decide anomalies (write skew).
• Child collection changes of an owned collection already bump the parent version unless @OptimisticLock(excluded = true).

JPA mandates EAGER for @ManyToOne and @OneToOne, LAZY for collections. Eager to-one associations get loaded by find (join) but by JPQL as extra selects (N+1). Set fetch = LAZY on all associations and fetch explicitly per use case.

• Lazy to-one on the non-owning side of @OneToOne often cannot be proxied (Hibernate must query to know null vs not null) unless using @MapsId or bytecode enhancement.
• Lazy proxies make getClass() comparisons and final classes/methods problematic.

Hibernate 6 maps AUTO for Long to SEQUENCE (one sequence per entity named <entity>_seq, allocationSize 50) on databases that support sequences, instead of the shared hibernate_sequence of Hibernate 5. Existing schemas then fail with "sequence not found" or ID collisions.

• Fix: declare @SequenceGenerator(name=..., sequenceName=..., allocationSize=...) explicitly, or alter the sequences to INCREMENT BY 50 and start beyond the current max.
• For MySQL, AUTO resolves to IDENTITY. UUID types generate UUIDs under AUTO.

Select only needed columns directly into a record or interface projection, which skips the persistence context, dirty checking and hydration of unused columns/associations.

public record OrderSummary(Long id, String status, BigDecimal total) {}

@Query("select new com.acme.OrderSummary(o.id, o.status, o.total) from Order o where o.customer.id = :cid")
List<OrderSummary> findSummaries(Long cid);

• Spring Data also supports interface-based projections (closed projections select only declared properties; open ones with SpEL load the entity) and dynamic Class<T> parameters.
• Projections are not managed, so changes are not persisted.

Spring Boot enables spring.jpa.open-in-view=true by default, keeping the EntityManager open through view rendering, so lazy loads in controllers or serializers work. If it is disabled in one profile (recommended for production), lazy access outside the transaction throws.

• OSIV holds a DB connection for the whole request including slow serialization or remote calls, which exhausts the Hikari pool under load.
• Better design: fetch what the use case needs inside the service (JOIN FETCH, entity graph, DTO), and return DTOs.
• Boot logs a warning at startup when OSIV is on.

Spring applies transactions through proxies, so only calls entering through the bean proxy go through the interceptor. Self-invocation and private methods bypass it, so there is no transaction and, for JPA, no flush and no dirty checking.

• With OSIV on you may get a session but changes are never flushed; with it off, a lazy load throws.
• Fix: move the method into another bean, inject self carefully, or use TransactionTemplate.

Bulk JPQL updates go straight to the database, bypassing the persistence context; already loaded entities keep stale state and the @Version is not bumped.

• Use @Modifying(clearAutomatically = true, flushAutomatically = true) so pending changes are flushed first and the context cleared afterward.
• Or update versioned HQL if optimistic locking must be respected.
• Cascade, lifecycle callbacks and entity listeners do not run for bulk operations.

Use @Enumerated(EnumType.STRING). The default ORDINAL stores the position, so inserting or reordering constants silently changes the meaning of existing rows.

• STRING costs more storage and renaming a constant needs a migration. A custom AttributeConverter storing a stable code decouples the DB from Java names.
• Hibernate 6.2+ can map enums to native DB enum types / check constraints via @JdbcTypeCode.

update only adds missing tables/columns; it never drops or alters safely, cannot rename, offers no review or rollback, and runs on every instance at startup. Use Flyway or Liquibase for versioned migrations and ddl-auto=validate (or none) in production.

• Embedded test databases default to create-drop.
• Spring Boot runs Flyway before the EntityManagerFactory is initialized, so validate sees the migrated schema.

Embed the type twice and override column names with @AttributeOverrides, otherwise both embedded fields map to the same columns and Hibernate fails with a duplicate-column mapping error.

@Embedded
@AttributeOverrides({
  @AttributeOverride(name = "street", column = @Column(name = "ship_street")),
  @AttributeOverride(name = "city",   column = @Column(name = "ship_city"))
})
private Address shipping;

• Embeddables have no identity and are managed with the owner; an all-null embedded value is loaded as null rather than an empty object.
• Java records can be embeddables from Hibernate 6.2.

Flush cost grows with the number of managed entities because dirty checking compares every one at each flush (including auto flushes before queries). Check for queries inside loops triggering auto-flush, large persistence context, and the ID generator.

• Reduce the context size (chunk and clear()), move queries before mutations, set FlushModeType.COMMIT for read-heavy sections, or use @Transactional(readOnly = true) where possible.
• Use bytecode enhancement (dirty tracking) to avoid snapshot comparison for large graphs.
• Check for IDENTITY (one round trip per row) and missing batching.

It runs in a new connection and a new persistence context, so it sees only committed data, not the outer transaction's uncommitted changes. If it updates the same row the outer transaction has locked, the call blocks and can deadlock the thread with itself.

• With a bounded pool, nested REQUIRES_NEW holds two connections per request; at pool size N concurrent requests can deadlock waiting for a second connection.
• The entity from the outer context is a different instance than the inner copy; merging back leads to stale state.

The derived query matched more than one row, so a single-result return type fails. Fix the data or the query: add a unique constraint, use findFirstBy...OrderBy..., Top1, or return a List/Page.

• A unique constraint at the DB level is the real guarantee; an application check is racy.
• existsBy is cheaper than findBy plus null check.