2009-10-28 4 views
3

У меня есть класс AbstractEntity как суперкласс для всех моих entites, который определяет оптимистическую колонку блокировки, как это:OptimisticLocking и @OneToMany (mappedBy = ...) обработка?

@Version 
private long lockVersion; 

Теперь я часто получаю OptimisticLockingExceptions на лицах, которые изменены только в одном отношениях mappedBy подобное следующим :

@OneToMany(mappedBy = Property.PROPERTY_DESCRIPTOR, cascade = { CascadeType.REMOVE }) 
private Set<Property> properties = new HashSet<Property>(); 

Можно ли исключить эти коллекции из оптимистической блокировки Hibernate? Сущность не изменяется в базе данных вообще ... только другие ссылаются на нее.

ответ

2

Вы можете исключить определенное свойство (и/или сбор) с увеличением номера версии, если он грязный, явно исключая его через @OptimisticLock аннотацию:

@OptimisticLock(excluded=true) 
@OneToMany(mappedBy = Property.PROPERTY_DESCRIPTOR, cascade = { CascadeType.REMOVE }) 
private Set<Property> properties = new HashSet<Property>(); 

Имейте в виду, что это расширение Hibernate стандарту JPA.

+0

Это выглядит многообещающе ... Я проверю, решает ли он мои проблемы. –

+0

Я добавил эту аннотацию ко всем коллекциям MappedBy, которые не каскадируются либо слиянием, либо сохранением. Альтернативное решение состоит в том, чтобы различать entity.getCollection(). Add (...) для неуправляемых объектов и em.refresh (entity) для управляемых объектов. Это позволяет избежать проблем с блокировкой. –

0

я думаю, что принятый ответ на этот вопрос должен помочь вам: link

Я havn't пробовал сам, хотя, но это может быть возможным, чтобы обнаружить изменения, не требующие обновления версии, а не увеличивать версию.

+0

Хмм может быть ... но я надеялся на какую-то функцию аннотации или спящего режима, чтобы решить эту проблему ... посмотрим. –

+0

Согласен, это немного хакерский ... – Tomas

Смежные вопросы