Когда явно исключать оптимистическую блокировку (спящий режим)?

Question

При каких обстоятельствах было бы целесообразным явно исключить оптимистическую блокировку из отношения @OneToMany через Hibernate?

Я читал пост в Hibernate, в котором в основном говорится, что любые обновления дочерних сущностей вызовут оптимистическую блокировку родительской сущности, которая обычно не нужна. Ключевое слово здесь , обычно ... может кто-нибудь объяснить более точно, когда вам понадобится или не понадобится оптимистическая блокировка таких отношений?

Ниже приведен пример кода, демонстрирующий исключение оптимистической блокировки:

// Bars - these are specifically excluded from optimist lock
// for the object, since we don't want to obtain optimistic
// lock when we add a new bar
@OptimisticLock(excluded = true)
@OneToMany
@JoinColumn(name = "FOO_ID", nullable = false, updatable = false)
private List<FooBar> bars = new LinkedList<FooBar>();

Answer 1

По сути, вам нужна оптимистическая блокировка для отношений один-ко-многим, когда родитель логически «владеет» своими дочерними элементами, другими словами, когда родительские и дочерние элементы изменяются одновременно в целом.Order, состоящий из OrderLine s, которые представлены пользователю в одной форме, может быть примером такого рода отношений.

В противном случае, когда дети должны быть изменены индивидуально, они должны бытьисключен из оптимистической блокировки.Topic с Post s может быть примером этого случая.

Технически говоря, этот вопрос связан с направленностью отношений.Целью оптимистической блокировки является предотвращение потерянных модификаций, поэтому вам необходимо включить ее для отношений один-ко-многим, когда возможны потерянные модификации.Это происходит, когда родитель является собственной стороной отношений, другими словами, когда отношения один ко многим однонаправлены (обратите внимание, что это естественный выбор для моделирования отношений, таких как Order - OrderLine),

В случае двунаправленных отношений «один ко многим» сторона «многие» является стороной-владельцем, поэтому модификации отношений на стороне «один» не влияют на базу данных, поэтому онине может быть потеряно.