What are you not allowed to do inside a @PreUpdate or @PostPersist callback method on a JPA entity, and which kinds of data changes will never trigger those callbacks at all?

## Where a callback actually executes Pre- and post-write callbacks do not run at your call site. They run inside the provider's flush, while it is walking an ordered queue of pending insert, update, delete and collection actions and issuing JDBC statements. Understanding that single fact explains every restriction. ## The restrictions **No EntityManager or Query operations.** Calling `persist`, `merge`, `remove`, `find`, or executing a query from inside a callback is outside the specification. Real failure modes when you do it anyway: adding an action to a queue that is being iterated (concurrent modification), triggering a nested flush while a flush is in progress, or creating a cycle where saving A causes a save of B whose callback saves A. Providers may tolerate some of it, in some versions, for some operations — which is worse than an outright ban, because it works in a unit test and fails under a different flush order in production. **No access to other entity instances.** Same reason: their state may be mid-flush, and reading an uninitialised lazy association may trigger loading at a moment the provider does not expect. **Allowed and intended**: mutating the state of the very entity the callback was invoked for. In `@PrePersist` and `@PreUpdate` those mutations land in the statement being built, which is what makes timestamp stamping work. In the *post* callbacks they do not — the statement is already out; a later flush might pick them up, or nothing will. **Exceptions**: checked exceptions are not permitted in the signature. An unchecked exception propagates out of the operation and the transaction is marked for rollback. That makes `@PreRemove` a viable veto point ('this entity cannot be deleted while it has open orders'), but a crude one — it aborts the whole transaction. ## What never triggers a callback **Bulk JPQL/HQL `update` and `delete`.** These compile to a single SQL statement operating over rows. No entity is loaded, so no callback runs, no version column is bumped unless you write it yourself, and the persistence context can be left holding stale copies of the affected rows. It is the single most common way an audit or timestamp scheme silently develops holes. **Native SQL** executed through the provider or through a raw connection: same, and even more invisible. **Writes from outside the application**: another service, a scheduled job, a migration script, a human with psql. Anything built purely on callbacks is blind to them. **Non-dirty 'changes'.** Hibernate compares the entity against the snapshot taken when it was loaded. A setter that writes an equal value produces no UPDATE and therefore no `@PreUpdate`. Similarly, an entity that was never managed — modified while detached and never merged — never enters the comparison at all. **Collection-only changes on the owning entity.** If you add an element to a `@OneToMany` mapped by the other side, the parent's own columns are unchanged; Hibernate updates the child's foreign key, not the parent row. So the parent's `@PreUpdate` does not fire, and an `updatedAt` scheme that is supposed to reflect 'the aggregate changed' does not move. (`@OptimisticLock` on the collection can be used to force a version bump on the owner, which changes this behaviour deliberately.) **Cascading deletes performed by the database.** If the schema has `ON DELETE CASCADE` and the provider deletes the parent, the children's rows vanish server-side without the provider ever loading them, so no `@PreRemove` runs for them. ## Timing versus commit Post-write callbacks fire after the statement executes but inside the transaction. If you send an email, publish to a message broker, or call another service from `@PostPersist`, and the transaction subsequently rolls back — for a constraint violation later in the same flush, an optimistic-lock failure, or an exception in surrounding code — you have announced an event that never happened. The correct shape for anything with an external side effect is to record the intent inside the transaction (an outbox row) and act after commit; at the Hibernate level, post-commit event listeners exist precisely because callbacks cannot express 'after commit'. ## How to state this in an interview One sentence for the mechanism ('callbacks run inside flush, on managed entities'), then the two consequences: you may not re-enter the persistence context, and anything that changes rows without going through a managed entity is invisible. Then the commit-timing caveat. That is the complete answer, and it is the one that separates someone who has used callbacks from someone who has been burned by them.