Всем привет! Есть достаточно распространенная задача: нужно вставить новую запись в БД, но если она уже там есть, то её следует обновить. Эта ситуация может встретиться, например, если у вас есть 2 источника данных, каждый из которых передает половину информации об объекте, и ваш сервис должен склеить части вместе по какому‑то внешнему идентификатору. Но вы не знаете, в каком порядке к вам попадут эти половинки. Предлагаю посмотреть, как это можно сделать, если сервис использует Spring Data JPA.

А в чем вообще проблема?

Возьмем очевидную реализацию этого сервиса на Spring Data JPA:

@Transactional
public Item saveOrUpdate(ItemDto dto) {
  Item item = repository.findItemByExternalId(dto.getExternalId())
    .map(existed -> updateEntity(existed, dto))
    .orElseGet(() -> createNewEntity(dto));

  return repository.save(item);
}

Здесь мы ищем сущность по внешнему идентификатору, используя JpaRepository. Если находим — обновляем ее данными из DTO‑объекта (в методе updateEntity), если не находим — создаем новую (вызываем метод createNewEntity). В обоих случаях сохраняем результат в БД, вызывая repository.save.

Что случится, если этот метод будет вызван одновременно для одного и того же внешнего идентификатора? Ну, один из возможных ответов — все будет ОК, мы тут используем механизмы EntityManager’а, который такие проблемы успешно порешает за нас (спойлер — не порешает). Если запись в БД есть — EntityManager использует update, если нет — использует insert. Удивительно, но так в интернетах думают достаточно многие — вот первые ссылки по запросу JPA upsert из гугла:

• Spring JPA: How to upsert without losing data

• How To Update Or Insert A Record In Spring Data JPA

Ни в одной из них даже не рассматривается вариант, что мы получим какие‑то проблемы. Чтобы немного засомневаться в том, так ли это, достаточно подумать, что сможет сделать EntityManager, если у нас несколько инстансов? Он же так или иначе работает на базе своего внутреннего кэша, поэтому 2 разных инстанса сходят в базу, увидят, что объекта с таким идентификатором там еще нет, и оба попробуют выполнить insert. На самом деле, и один инстанс сервиса сделает то же самое, потому что кэш EntityManager’а ограничен текущей транзакцией. В итоге, первый insert выполнится успешно, а второй — свалится с ошибкой вставки по уникальному ключу (если вы, конечно, создали для внешнего идентификатора уникальный индекс).

Lock'и

Окей, у JPA и у Spring Data есть функциональность работы с блокировками (Lock). Они же нам помогут? На самом деле, нет. Блокировки действительно решают проблему конкуретных обновлений данных, но для этого данные должны уже быть в базе. Использование PESSIMISTIC_LOCK обычно сводится к запросу SELECT FOR UPDATE, оптимистичные блокировки используют специальное поле версии при обновлении, и убеждаются что версия данных в БД не отличается от той, что в памяти. Но когда записи в базе еще нет, то оба подхода приведут к выполнению двух insert’ов.

Внешняя блокировка

Перейдем к вариантам, которые будут работать. Первый является продолжением попыток на чем‑нибудь синхронизироваться. Если мы не можем синхронизироваться на самой обновляемой сущности, потому что ее еще нет в БД, давайте синхронизируемся на чем‑нибудь еще, что там уже есть. Сделаем в БД отдельную таблицу для блокировок, вставим туда строку, которая будет соответствовать нашей таблице для Item. Если мы хотим что‑то изменить в таблице сущностей, сначала получим блокировку на соответствующей строке в таблице блокировок.

Сложно? Тогда есть вариант не изобретать свои велосипеды. Мы же используем Spring — там есть все. Даже если вы хотите в своем приложении реализовать черта лысого, наверняка найдется уже готовая спринговая библиотека с ним внутри (и еще starter‑версия с автоконфигурацией). В частности, в этой задаче может помочь интерфейс LockRegistry и реализация JdbcLockRegistry в spring‑boot‑starter‑integration и spring‑integration‑jdbc соответственно. Там используется подход, который отличается от того, который я описал. В частности, блокировка происходит по ключу, а не по типу сущности, но суть одна — создать возможность залочиться на объекте БД, не связанном с основной бизнес‑логикой.

@Transactional
public Item saveOrUpdate(ItemDto dto) {
  Lock lock = lockRegistry.obtain(dto.getExternalId().toString());
  try {
    if(lock.tryLock(250, TimeUnit.MILLISECONDS)) {
      try {
        Item item = repository.findItemByExternalId(dto.getExternalId())
          .map(existed -> updateEntity(existed, dto))
          .orElseGet(() -> createNewEntity(dto));

        return repository.save(item);
      } finally {
        lock.unlock();
      }
    } else {
      String errorMsg = "Could not acquire lock for " + dto.getExternalId();
      log.error(errorMsg);
      throw new DBException(errorMsg);
    }
  } catch (InterruptedException e) {
    String errorMsg = "Lock acquiring interrupted for " + dto.getExternalId();
    log.error(errorMsg);
    throw new DBException(errorMsg);
  }
}

@Bean
public LockRepository lockRepository(DataSource dataSource) {
    var lockRepository = new DefaultLockRepository(dataSource);
    lockRepository.setTransactionManager(new DataSourceTransactionManager(dataSource));
    return lockRepository;
}

@Bean
public LockRegistry lockRegistry(LockRepository lockRepository) {
    return new JdbcLockRegistry(lockRepository);
}

Native Query

Использование Native Query, наверное, самый очевидный способ решения задачи. Наша проблема связана с тем, что стандартные средства Spring Data и JPA не позволяют выполнить проверку наличия записи в БД и вставку/обновление в одно действие. Поэтому нам приходится как‑то обеспечивать корректное согласованное выполнение этих двух операций. Но если операция будет одна, то проблему удастся переложить на БД. Большинство вендоров имеют возможности для того, чтобы выполнить такую операцию за один вызов. В случае PostgreSQL, это выражение insert on conflict do update. Вот так может выглядеть кастомный метод в репозитории:

@Query(value = "insert into item (external_id, foo, bar) " +
               "  values (:#{#entity.external_id}, :#{#entity.foo}, :#{#entity.bar}) " + 
               "  on conflict(external_id) do update set foo = coalesce(excluded.foo, item.foo), " +
               "    bar = coalesce(excluded.bar, item.bar) " +
               "  returning *", nativeQuery = true)
Item saveOrUpdate(Item entity);

Оригинальный запрос не использовал returning * и возвращал количество измененных строк. Поменял его, после того как @oxff в комментариях указал на возможность сразу получать обновленную сущность в Native Query

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

В целом, подход с Native Query эффективно решает проблему, но имеет свои недостатки:

• логика обновления оказывается на стороне базы (обратите внимание на coalesce в приведенном примере — это как раз выбор, оставить старые данные или использовать новые);

• NativeQuery возвращает количество измененных строк, а не сохраненный объект. Чтобы получить этот объект, нам надо выполнять отдельный запрос в БД, и при этом нет гарантий, что мы получим ровно то, что сами только что вставили;

• код приложения зависит от используемой БД (этот недостаток принято преувеличивать. Я ни разу не встречал ситуацию, когда переезд на другую базу действительно бы выполнялся по щелчку пальцев. Это всегда была отдельная трудоемкая активность. Поэтому так ли важно пытаться сохранять «базонезависимость» в коде, вместо того, чтобы использовать специфику БД точечно там, где она нужна?);

• такой подход противоречит идее Spring Data — вы используете технологию, которая освобождает даже от написания JPQL, и тут же пишете на Native SQL. Вернее, он не то, чтобы противоречит, но заставляет задуматься, а правильно ли вы выбрали инструментарий. Хорошо когда на 99 стандартных вызовов репозитория приходится один такой хитросделанный, но если у вас на 10 вызовов 8 содержат какой‑то тюнинг, то зачем вам вообще Spring Data?

• требуются более глубокие знания о той БД, с которой работает приложение.

Повтор операций

Наименее распространенный способ, на мой взгляд. Если вы получили ошибку при выполнении второго insert'а из‑за ограничений целостности, просто повторите операцию еще раз. При втором запуске приложение получит Item из базы и успешно выполнит обновление.

В случае Spring‑приложений у нас есть удобный механизм повтора — аннотация Retryable (не забудьте при ее использовании указать в конфигурации @EnableRetry). Если произошло нарушение уникального индекса операцию можно повторять сразу же. Если вы решаете проблемы с повтором операции из‑за уровня изоляции, то надо быть более осторожным: с настройками по умолчанию обе конкурирующие транзакции откатятся и после одинаковой задержки в 1 секунду одновременно повторятся. Поэтому с большой вероятностью опять случится конфликт. Чтобы этого избежать, можно использовать случайную задержку при повторе.

@Retryable(backoff = @Backoff(delay = 1, maxDelay = 100, random = true))
@Transactional(isolation = Isolation.SERIALIZABLE)
public Item saveOrUpdate(ItemDto dto) ...

Итоги

Upsert с использованием Spring Data JPA можно реализовать несколькими способами, у каждого из которых свои достоинства и недостатки:

1. Внешние блокировки усложняют код, снижают производительность и увеличивают нагрузку на БД, но при этом приложение не снижает свой уровень абстракции. Для этого вообще не обязательно использовать БД, Spring предоставляет реализацию с Redis'ом. Также этот подход может применяться для корректного конкурентного доступа не только к БД, но и к любым ресурсам;

2. Native Query полагается на способность БД эффективно реализовать слияние данных за одну операцию. И поэтому сильно зависит от того, какую БД вы используете. Кроме этого, обновление и чтение обновленных данных все равно окажутся разными операциями;

3. Повтор операций увеличивает время отклика и заставляет быть внимательным к side‑effect'ам повторяемого метода. И при этом, в некоторых случаях, вообще нет гарантии, что он поможет. Но зато он крайне прост в реализации.