Оптимистическая блокировка в приложении без сохранения состояния с помощью JPA/Hibernate

Ответ 1

  Сервер загружает элемент с EntityManager, который возвращает Item (id = 1, version = 1, name = "a"), он меняет имя и сохраняет Item (id = 1, version = 1, name = "b"). Hibernate увеличивает версию до 2.

Это неправильное использование API JPA и основная причина вашей ошибки.

Если вместо этого использовать entityManager.merge(itemFromClient), версия оптимистической блокировки будет проверена автоматически, а "обновления из прошлого" отклонены.

Одно предостережение заключается в том, что entityManager.merge объединит все состояние объекта. Если вы хотите обновить только определенные поля, то с простым JPA все будет немного не в порядке. В частности, поскольку вы не можете назначать свойство version, вы должны проверить версию самостоятельно. Однако этот код легко использовать повторно:

<E extends BaseEntity> E find(E clientEntity) {
    E entity = entityManager.find(clientEntity.getClass(), clientEntity.getId());
    if (entity.getVersion() != clientEntity.getVersion()) {
        throw new ObjectOptimisticLockingFailureException(...);
    }
    return entity;
}

и тогда вы можете просто сделать:

public Item updateItem(Item itemFromClient) {
    Item item = find(itemFromClient);
    item.setName(itemFromClient.getName());
    return item;
}

в зависимости от характера полей, которые нельзя изменить, вы также можете сделать следующее:

public Item updateItem(Item itemFromClient) {
    Item item = entityManager.merge(itemFromClient);
    item.setLastUpdated(now());
}

Что касается выполнения DDD, проверка версии является деталью реализации технологии персистентности, и поэтому должна происходить в реализации репозитория.

Чтобы передать версию через различные слои приложения, я считаю удобным сделать версию частью сущности домена или объекта значения. Таким образом, другие слои не должны явно взаимодействовать с полем версии.

Ответ 2

Когда вы загружаете запись из БД для обработки запроса на обновление, вы должны сконфигурировать этот загруженный экземпляр, чтобы та же версия была предоставлена клиентом. Но, к сожалению, когда объектом управляют, его версию нельзя изменить вручную, как того требует спецификация JPA.

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

// the version in the input parameter is the version supplied from the client
public Item findById(Integer itemId, Integer version){
    Item item = entityManager.find(Item.class, itemId);

    if(!item.getVersoin().equals(version)){
      throws  new OptimisticLockException();
    }
    return item;
}

Поскольку озабоченность по поводу API будет загрязнена параметром version, я бы смоделировал entityId и version как концепцию домена, которая представлена объектом значения с именем EntityIdentifier:

public class EntityIdentifier {
    private Integer id;
    private Integer version;
}

Затем имейте BaseRepository, чтобы загрузить сущность с помощью EntityIdentifier. Если значение version в EntityIdentifier равно NULL, оно будет считаться самой последней версией. Все репозитории других объектов будут расширять его для повторного использования этого метода:

public abstract class BaseRepository<T extends Entity> {

    private EntityManager entityManager;

    public T findById(EntityIdentifier identifier){

         T t = entityManager.find(getEntityClass(), identifier.getId());    

        if(identifier.getVersion() != null && !t.getVersion().equals(identifier.getVersion())){
            throws new OptimisticLockException();
        }
        return t;
 } 

^{Note: This method does not mean loading the state of the entity at an exact version since we are not doing event sourcing here and will not store the entity state at every version. The state of the loaded entity will always be the latest version , the version in EntityIdentifier is just for handling the optimistic locking.}

Чтобы сделать его более универсальным и простым в использовании, я также определю интерфейс EntityBackable так, чтобы BaseRepository мог загрузить объект с резервной копией чего-либо (например, DTO), как только они его реализуют.

public interface EntityBackable{
    public EntityIdentifier getBackedEntityIdentifier();
}

И добавьте следующий метод в BaseRepository:

 public T findById(EntityBackable eb){
     return findById(eb.getBackedEntityIdentifier());
 }

Итак, в конце служба приложений ItemDto и updateItem() выглядит следующим образом:

public class ItemDto implements EntityBackable {

    private Integer id;
    private Integer version;

    @Override
    public EntityIdentifier getBackedEntityIdentifier(){
         return new EntityIdentifier(id ,version);
    }
}

@Transactional
public void changeName(ItemDto dto){
    Item item = itemRepository.findById(dto);
    item.changeName(dto.getName());
}

Подводя итог, это решение может:

• Единица работы по-прежнему действительна
• API хранилища не будет заполнен параметром версии
• Все технические подробности об управлении версией заключены в BaseRepository, поэтому никакие технические подробности не просочились в домен.

Примечание:

• setVersion() по-прежнему необходимо раскрывать из сущности домена. Но я согласен с этим, поскольку сущность, получаемая из хранилища, управляется, что означает, что на сущность не влияют даже те вызовы, которые вызывают разработчики setVersion(). Если вы действительно не хотите, чтобы разработчики звонили setVersion(). Вы можете просто добавить тест ArchUnit, чтобы убедиться, что он может быть вызван только из BaseRepository.

Ответ 3

Все объяснения и предложения, сделанные здесь, были очень полезны, но, поскольку окончательные решения немного отличаются, я думаю, что стоит поделиться им.

Манипулирование version напрямую не работало должным образом и конфликтует со спецификацией JPA, поэтому это не было вариантом.

Окончательное решение - явная проверка версии + автоматическая проверка версии JPA Hibernate. Явная проверка версии выполняется на прикладном уровне:

@Transactional
fun changeName(dto: ItemDto) {
    val item = itemRepository.findById(dto.id)
    rejectConcurrentModification(dto, item)
    item.changeName(dto.name)
}

Чтобы уменьшить количество повторений, проверка выполняется отдельным методом:

fun rejectConcurrentModification(dto: Versioned, entity: Versioned) {
    if (dto.version != entity.version) {
        throw ConcurrentModificationException(
            "Client providing version ${dto.version} tried to change " + 
            "entity with version ${entity.version}.")
    }
}

Сущности и DTO реализуют интерфейс Versioned:

interface Versioned {
    val version: Int
}

@Entity
class Item : Versioned {
    @Version
    override val version: Int = 0
}

data class ItemDto(override val version: Int) : Versioned

Но вытащить version из обоих и передать его в rejectConcurrentModification будет одинаково хорошо:

rejectConcurrentModification(dto.version, item.verion)

Очевидным недостатком явной проверки на уровне приложения является то, что о ней можно забыть. Но поскольку в любом случае хранилище должно обеспечивать способ загрузки сущности без версии, добавление версии в метод find хранилища также не будет безопасным.

Преимущество явной проверки версии на уровне приложения состоит в том, что она не загрязняет уровень домена, за исключением того, что version должен быть читаемым извне (путем реализации интерфейса Versioned). Методы объекта или хранилища, которые являются частью домена, не загрязнены параметрами version.

То, что явная проверка версии не выполняется в самый последний возможный момент времени, не имеет значения. Если между этой проверкой и окончательным обновлением базы данных другой пользователь изменит ту же сущность, то автоматическая проверка версии с помощью Hibernate вступит в силу, поскольку версия, загруженная в начале запроса на обновление, все еще находится в памяти (в стеке метод changeName в моем примере). Таким образом, первая явная проверка предотвратит одновременное изменение между началом редактирования на клиенте и явной проверкой версии. А автоматическая проверка версии предотвратит одновременное изменение между явной проверкой и окончательным обновлением базы данных.

Ответ 4

Чтобы предотвратить одновременные изменения, мы должны отслеживать, какая версия элемента где-то изменяется.

Если бы приложение имело состояние, у нас была бы возможность сохранить эту информацию на стороне сервера, возможно, во время сеанса, хотя это может быть не лучшим выбором.

В приложении без сохранения состояния эта информация должна идти до клиента и возвращаться с каждым изменяющим запросом.

Итак, IMO, если предотвращение одновременных изменений является функциональным требованием, то наличие информации о версии элемента в мутирующих вызовах API не загрязняет API, оно делает его полным.