Использование Spring 3.1/JPA 2, предоставляемое Hibernate 4.1.0.Hibernate/JPA @Version и @Generated вызывает StaleObjectStateException
У меня есть базовый класс для всех моих объектов, который предоставляет основные возможности аудита (обновлять временную метку, номер версии и т. Д.). Поскольку другие приложения обращаются к нашей базе данных, они должны быть установлены через Trigger.
Мой отображение выглядит следующим образом:
public abstract class AbstractBaseModel implements Serializable {
@Version
@Generated(GenerationTime.ALWAYS)
@Column(name = "VERSION", insertable = false, updatable = false)
protected Long version;
@Generated(GenerationTime.ALWAYS)
@Column(name = "UPDATE_TIMESTAMP", insertable = false, updatable = false)
protected Date updateDate;
...
}
org.hibernate.engine.internal.increment(...)
метод всегда вызывается при совершении сделки - и приводит к StaleObjectStateException
.
Как ни странно, если я установил GenerationTime.NEVER
на столбце версии, спящий режим все еще увеличивает версию, но сохраняется правильно. Проблема в том, что даже если версия в базе данных не обновляется (например, никаких изменений в таблице), версия, возвращаемая из слияния, будет на 1 выше, чем значение базы данных, что, очевидно, вызовет проблемы при последующих сбережениях.
Мое ожидание будет состоять в том, что GenerationTime.ALWAYS
скажет, что hibernate никогда не будет пытаться увеличить версию и полагаться на базу данных, чтобы сделать это, а затем после вставки/обновления, чтобы выбрать обновленное значение.
Может ли кто-нибудь сказать мне, где я ошибся в своем понимании и реализации?
О, как бы я хотел, чтобы вы решили мою проблему, но, к сожалению, нет. Это проявляет то же поведение, что и '@ Version' и' @ Generated'. Он всегда будет пытаться увеличить версию до того, как произойдет сброс, и вызовет оптимистическое блокирование. Все, что я хочу, это спящий режим, чтобы НЕ пытаться увеличивать поля, помеченные как '@ Generated', всегда ... Не уверен, что это особая проблема Oracle, но я полностью тупик. – Ben
Это действительно странно: этот код работает в нашей производственной среде в течение нескольких месяцев без каких-либо проблем. Мне очень жаль, что я не мог вам помочь, я действительно думал, что это решит вашу проблему ... – LeChe