Three kinds of write land the same 'system' value in Spring Data JPA's created_by

Spring Data offers one hook for every write, and it is a single method with no parameters: `Optional<T> getCurrentAuditor()` ^[4]. Nothing about the row being saved is passed in. Whatever the method returns has to come from state the thread performing the write can already reach ^[19]. In the author's services that state is a session-scoped bean holding the logged-in user, and the auditor reads from there instead of from Spring Security ^[5]. On a nightly archive thread the bean is not in scope. The post says the storage choice is beside the point: "the problem is not where the identity is stored. The problem is that on a scheduler thread there is no identity to read" ^[6].

The writes that land on the fallback are not one population. A nightly job that archives stale records never had a user ^[7]. A queue consumer that picks a command off a queue and executes it does have one, a real person whose identity got lost on the way ^[3]. An `@Async` method started inside a request finishes after the request is gone, so the identity existed and then went out of scope ^[7]. The text available stops mid-sentence in the note on `auditorAwareRef`, before the auditor component that decides what each of those cases returns ^[20].

The entity side is the part I would copy unchanged. `AuditableEntity` is a `@MappedSuperclass` with `AuditingEntityListener` attached and getters only, so the four fields are written by the listener and by nothing else ^[8]. Both created_* columns are declared `updatable = false`. A load, modify and merge cycle therefore leaves them out of the UPDATE ^[9]. The post argues that if application code can call setCreatedBy, sooner or later it will, usually in a migration or an import that somebody wrote in a hurry ^[10]. That closes one route to a wrong value, and it also means a service that has to correct created_by across a million rows does it in SQL, not through the entity.

The equals/hashCode note is easy to miss and expensive to relearn. Do not generate them over these fields: all four change the moment the entity is persisted, so an entity put in a `HashSet` before `save()` is a different object afterwards, and with Lombok that means `@Getter` on the superclass and not `@Data` ^[11]. The timestamps are `Instant` and not `LocalDateTime` because the trail gets read across services that may not share a timezone, and Spring Data converts `Instant` without configuration ^[12].

For the pattern to transfer, the shape has to match the one the post assumes: several Boot services, each with its own database, all persisting through JPA ^[17]. If identity lives in `SecurityContextHolder` instead of a session-scoped bean, none of the entity code changes and the gap on the off-request thread is exactly the same ^[6].