Мы используем Hibernate 5.3.13 с Spring Data JPA 2.1.12 и при наличии уже сохраненного управляемого минимального объекта, например следующего:
@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();
который содержит следующие Embeddable
@Embeddable
@Access(AccessType.FIELD)
class Events {
@OneToMany(mappedBy = ...)
@OrderBy("id ASC")
@BatchSize(size = 10)
List<Event> events = new LinkedList<>();
Теперь всякий раз, когда вы вызываете EventsHolder.events.add(...) с уже сохраненным управляемым событием, которое добавляется в коллекцию, спящий режим — при выполнении автоматической очистки — обнаружит коллекцию EventsHolder.Events.events как грязную в org.hibernate.event.internal.DefaultFlushEntityEventListener#hasDirtyCollections и выдаст (не уверен, является ли это важной предпосылкой здесь ) вызов Pre-Update для Spring Data AuditingHandler, который обновит модифицированный On.
В конце концов, optimisticLockingVersion будет увеличен, и hibernate выдаст оператор обновления, который в основном обновляет только измененную версию и версию.
С EventsHolder, который содержит 5000 событий, мы видим версии optlock около 4500-5000, а журнал аудита базы данных перегружен упомянутыми «не-обновлениями», которые обновляют только модифицированную версию и версию с оптимистичной блокировкой.
Любая идея о том, как остановить это поведение, очень ценится.
