1

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.

hotzen
  • 2,800
  • 1
  • 28
  • 42

1 Answers1

0

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.

hotzen
  • 2,800
  • 1
  • 28
  • 42