We are using Hibernate 5.3.13 with Spring Data JPA 2.1.12 and when having an already persisted, managed minimal Entity like the following:
@Entity
@Table(name = "EventsHolder")
@Access(AccessType.FIELD)
class EventsHolder {
@LastModifiedDate
@Column(name = "modifiedon", nullable = false)
@Temporal(TIMESTAMP)
@Access(AccessType.FIELD)
Date modifiedOn;
@Version
@Column(name = "optlock", nullable = false)
@Access(AccessType.FIELD)
long optimisticLockingVersion = 0L;
@Embedded
Events events = new Events();
that contains the following Embeddable
@Embeddable
@Access(AccessType.FIELD)
class Events {
@OneToMany(mappedBy = ...)
@OrderBy("id ASC")
@BatchSize(size = 10)
List<Event> events = new LinkedList<>();
Now, whenever calling EventsHolder.events.add(...)
with an already persisted, managed event that is added to the collection, hibernate - while doing auto-flushing - will detect the EventsHolder.Events.events
collection as being dirty in org.hibernate.event.internal.DefaultFlushEntityEventListener#hasDirtyCollections
and will issue (not sure whether this is an important prerequisite here) an Pre-Update call to Spring Data's AuditingHandler which will update the modifiedOn.
In the end, the optimisticLockingVersion will get incremented and hibernate issues an update statement that basically only updates modified-on and the version.
With EventsHolder that contain 5000 events we see optlock-versions around 4500-5000 and the database's audit-log is thrashed with said "non-updates" that only update modified-on and the optimistic-locking-version.
Any idea on how to stop this behaviour very much appreciated.
by removing the indirection - the embeddable Events
that only contained the @OneToMany-field and inlining it directly into the entity - the dirty-check was not continuously detecting the collection as dirty anymore and everything is fine now.