skip to content

Explain the mechanism behind JPA auditing: what AuditingEntityListener actually does, when fields are written, and why bulk updates and native queries escape it.

level: seniorimportance: should knowfreq 50%

answer

  1. @PrePersist sets created+modified; @PreUpdate sets modified only
  2. listener -> AuditingHandler -> DateTimeProvider + AuditorAware
  3. callbacks fire only on managed-entity flush
  4. bulk JPQL / native / JdbcTemplate bypass -> stale audit cols
  5. @EnableJpaAuditing bridges Spring beans into JPA-created listener

basics

~20 s

AuditingEntityListener is a JPA entity listener hooked to @PrePersist and @PreUpdate. When the persistence provider fires those callbacks, the listener sets the timestamp and auditor fields. Bulk JPQL and native SQL bypass the lifecycle, so no callback fires and audit fields aren't updated.

solid answer

~40 s

@EntityListeners(AuditingEntityListener.class) registers a JPA callback bean. The listener implements @PrePersist (sets created + modified fields) and @PreUpdate (sets only modified fields), delegating to an AuditingHandler that reads the clock via a DateTimeProvider and the principal via AuditorAware. Because these are JPA *entity lifecycle* callbacks, they only fire when Hibernate flushes managed-entity state changes — i.e. persist/merge of tracked entities. Bulk operations (@Modifying JPQL UPDATE/DELETE, native SQL, criteria bulk updates) run directly against the database without loading entities into the persistence context, so no PrePersist/PreUpdate is triggered and audit columns stay stale. Same for direct JDBC. The listener also needs Spring to inject its dependencies, which @EnableJpaAuditing arranges through a BeanFactory-aware configuration so the otherwise-JPA-managed listener can reach Spring beans.

code

java · 11 lines
java
// This bulk update does NOT trigger @PreUpdate -> lastModified* stays stale.
public interface ArticleRepository extends JpaRepository<Article, Long> {

    @Modifying
    @Query("update Article a set a.archived = true where a.createdDate < :cutoff")
    int archiveOld(@Param("cutoff") Instant cutoff);
}

// If you need audit columns updated in a bulk statement, set them yourself:
// "update Article a set a.archived = true, a.lastModifiedDate = :now,
//         a.lastModifiedBy = :who where ..."

go deeper

for a junior

Know the listener sets fields at persist/update time.

for a middle

Distinguish @PrePersist vs @PreUpdate behavior and know bulk updates skip auditing.

for a senior

Explain the AuditingHandler/DateTimeProvider/AuditorAware delegation and why lifecycle callbacks are bypassed by JPQL/native/JDBC.

for a principal

Reason about when the lifecycle-callback approach is insufficient and choose Envers, DB triggers, or CDC accordingly.

## The moving parts JPA auditing is a small pipeline: 1. **`@EntityListeners(AuditingEntityListener.class)`** — a standard JPA mechanism that attaches an external listener class to an entity. `AuditingEntityListener` is Spring Data's implementation. 2. **Lifecycle callbacks** — inside the listener, methods annotated `@PrePersist` and `@PreUpdate` (JPA callback annotations) run at the corresponding points in the entity lifecycle. 3. **`AuditingHandler`** (or `AuditingHandlerSupport`) — the actual worker the listener delegates to. `markCreated()` sets created+modified fields; `markModified()` sets only the modified fields. 4. **`DateTimeProvider`** — supplies "now" (default `CurrentDateTimeProvider`; overridable via `dateTimeProviderRef` for a fixed clock in tests). 5. **`AuditorAware`** — supplies the principal. ## When each field is written - **`@PrePersist`** (fires on `EntityManager.persist`, i.e. first INSERT): sets `@CreatedDate`, `@CreatedBy`, and also `@LastModifiedDate`/`@LastModifiedBy` (created and modified are equal at birth). - **`@PreUpdate`** (fires when a *managed* entity with dirty state is flushed/updated): sets only `@LastModifiedDate`/`@LastModifiedBy`; created fields are left alone. Crucially these are triggered by the persistence provider's dirty-checking / flush of *managed* entities. ## Why bulk / native operations escape auditing The callbacks are **entity-lifecycle** events. They require the entity to pass through the persistence context. Operations that do NOT do this bypass auditing entirely: - **Bulk JPQL** via `@Modifying` `UPDATE Article a SET a.title = ...` — executes as a single SQL statement; no entities are loaded, no `@PreUpdate` fires. `@LastModifiedDate/By` are NOT bumped. - **Native SQL** (`@Query(nativeQuery = true)` writes, `EntityManager.createNativeQuery(...).executeUpdate()`). - **Criteria `CriteriaUpdate`/`CriteriaDelete`** bulk operations. - **Direct JDBC / `JdbcTemplate`**. This is the single most common auditing surprise: developers optimize a mass update into a JPQL bulk statement and silently lose the modified-metadata. If you need auditing there, set the columns explicitly in the update statement. ## Dependency injection into a JPA-managed listener A subtlety: JPA instantiates entity listeners, not Spring — so how does `AuditingEntityListener` get its Spring-managed `AuditingHandler`? `@EnableJpaAuditing` wires an infrastructure setup (`AuditingBeanFactoryPostProcessor` / a configuration that hands the listener an `ObjectFactory<AuditingHandler>`) so the listener can lazily resolve its handler from the Spring context even though the listener object itself is created by the JPA provider. That's why you must not forget `@EnableJpaAuditing` — it's not just a flag, it builds the bridge. ## Other edge cases - **`@Version` / optimistic locking** interacts fine — both `@PreUpdate` auditing and version bump happen on flush. - **No-op updates**: if nothing is dirty, no `@PreUpdate` fires, so `@LastModifiedDate` won't advance just because you called `save()` on an unchanged managed entity. - **`updatable = false`** on the created columns is a belt-and-suspenders guard so an accidental re-write can't overwrite creation metadata at the SQL level. - **Cascade persists** to child entities that also carry the listener are audited independently. - **Testing time**: inject a fixed `DateTimeProvider` via `dateTimeProviderRef` for deterministic timestamps.

  • You call save() on a managed entity that hasn't changed. Does @LastModifiedDate advance?
    No. With no dirty state there's no flush-time UPDATE, so @PreUpdate doesn't fire and the timestamp is unchanged. Auditing tracks actual state changes, not save() invocations.
  • How do you make timestamps deterministic in tests?
    Provide a fixed DateTimeProvider bean and point @EnableJpaAuditing(dateTimeProviderRef = "...") at it, so the AuditingHandler reads a controlled clock instead of the real one.

saying these in an interview costs you the question

  • Believing a bulk @Modifying JPQL update triggers @LastModifiedDate/By
  • Thinking @PreUpdate also re-writes @CreatedDate
  • Assuming save() always advances the modified timestamp even with no changes
  • Not knowing @EnableJpaAuditing is what injects Spring beans into the JPA listener

context

resolving links…