Найти или вставить на основе уникального ключа с помощью Hibernate

У меня было аналогичное требование к пакетной обработке, когда процессы выполнялись на нескольких JVM. Подход, который я выбрал для этого, был следующим. Это очень похоже на предложение Джталборна. Однако, как указал vbence, если вы используете транзакцию NESTED, когда вы получаете исключение нарушения ограничения, ваш сеанс становится недействительным. Вместо этого я использую REQUIRES_NEW, который приостанавливает текущую транзакцию и создает новую, независимую транзакцию. Если новая транзакция откатится, это не повлияет на исходную транзакцию.

Я использую TransactionTemplate Spring, но я уверен, что вы можете легко перевести его, если не хотите зависимости от Spring.

public T findOrCreate(final T t) throws InvalidRecordException {
   // 1) look for the record
   T found = findUnique(t);
   if (found != null)
     return found;
   // 2) if not found, start a new, independent transaction
   TransactionTemplate tt = new TransactionTemplate((PlatformTransactionManager)
                                            transactionManager);
   tt.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
   try {
     found = (T)tt.execute(new TransactionCallback<T>() {
        try {
            // 3) store the record in this new transaction
            return store(t);
        } catch (ConstraintViolationException e) {
            // another thread or process created this already, possibly
            // between 1) and 2)
            status.setRollbackOnly();
            return null;
        }
     });
     // 4) if we failed to create the record in the second transaction, found will
     // still be null; however, this would happy only if another process
     // created the record. let's see what they made for us!
     if (found == null)
        found = findUnique(t);
   } catch (...) {
     // handle exceptions
   }
   return found;
}

Вам нужно использовать UPSERT или MERGE для достижения этой цели.

Однако Hibernate не поддерживает эту конструкцию, поэтому вам нужно использовать jOOQ.

private PostDetailsRecord upsertPostDetails(
        DSLContext sql, Long id, String owner, Timestamp timestamp) {
    sql
    .insertInto(POST_DETAILS)
    .columns(POST_DETAILS.ID, POST_DETAILS.CREATED_BY, POST_DETAILS.CREATED_ON)
    .values(id, owner, timestamp)
    .onDuplicateKeyIgnore()
    .execute();

    return sql.selectFrom(POST_DETAILS)
    .where(field(POST_DETAILS.ID).eq(id))
    .fetchOne();
}

Вызов этого метода в PostgreSQL:

PostDetailsRecord postDetailsRecord = upsertPostDetails(
    sql, 
    1L, 
    "Alice",
    Timestamp.from(LocalDateTime.now().toInstant(ZoneOffset.UTC))
);

Выдает следующие операторы SQL:

INSERT INTO "post_details" ("id", "created_by", "created_on") 
VALUES (1, 'Alice',  CAST('2016-08-11 12:56:01.831' AS timestamp))
ON CONFLICT  DO NOTHING;
    
SELECT "public"."post_details"."id",
       "public"."post_details"."created_by",
       "public"."post_details"."created_on",
       "public"."post_details"."updated_by",
       "public"."post_details"."updated_on"
FROM "public"."post_details"
WHERE "public"."post_details"."id" = 1

В Oracle и SQL Server jOOQ будет использовать MERGE, а в MySQL — ON DUPLICATE KEY.

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

Код доступен на GitHub.

На ум приходят два решения:

Вот для чего нужны TABLE LOCK

Hibernate не поддерживает блокировки таблиц, но это тот случай, когда они пригодятся. К счастью, вы можете использовать собственный SQL через Session.createSQLQuery(). Например (в MySQL):

// no access to the table for any other clients
session.createSQLQuery("LOCK TABLES foo WRITE").executeUpdate();

// safe zone
Foo foo = session.createCriteria(Foo.class).add(eq("name", name)).uniqueResult();
if (foo == null) {
    foo = new Foo();
    foo.setName(name)
    session.save(foo);
}

// releasing locks
session.createSQLQuery("UNLOCK TABLES").executeUpdate();

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

А как насчет замков Hibernate?

Hibernate использует блокировку на уровне строк. Мы не можем использовать его напрямую, потому что мы не можем заблокировать несуществующие строки. Но мы можем создать фиктивную таблицу с одной записью, сопоставить ее с ORM, а затем использовать блокировки в стиле SELECT ... FOR UPDATE для этого объекта для синхронизации наших клиентов. По сути, нам нужно только убедиться, что никакие другие клиенты (работающие с тем же программным обеспечением и с теми же соглашениями) не будут выполнять какие-либо конфликтующие операции, пока мы работаем.

// begin transaction
Transaction transaction = session.beginTransaction();

// blocks until any other client holds the lock
session.load("dummy", 1, LockOptions.UPGRADE);

// virtual safe zone
Foo foo = session.createCriteria(Foo.class).add(eq("name", name)).uniqueResult();
if (foo == null) {
    foo = new Foo();
    foo.setName(name)
    session.save(foo);
}

// ends transaction (releasing locks)
transaction.commit();

Ваша база данных должна знать синтаксис SELECT ... FOR UPDATE (Hibernate собирается использовать его), и, конечно, это работает, только если все ваши клиенты имеют одно и то же соглашение (им нужно блокировать один и тот же фиктивный объект).

документация Hibernate по транзакциям and exceptions указывает, что все HibernateExceptions неисправимы и что текущая транзакция должна быть отменена, как только она будет обнаружена. Это объясняет, почему приведенный выше код не работает. В конечном счете, вы никогда не должны перехватывать HibernateException без выхода из транзакции и закрытия сеанса.

Казалось бы, единственный реальный способ добиться этого — управлять закрытием старого сеанса и повторным открытием нового внутри самого метода. Основываясь на том, что я обнаружил, реализация метода findOrCreate, который может участвовать в существующей транзакции и является безопасным в распределенной среде, кажется невозможной с использованием Hibernate.

Решение на самом деле очень простое. Сначала выполните выбор, используя значение вашего имени. Если результат найден, верните его. Если нет, создайте новый. В случае сбоя создания (с исключением) это происходит потому, что другой клиент добавил это же самое значение между вашим оператором select и вашим оператором вставки. Тогда логично, что у вас есть исключение. Поймай его, откатай свою транзакцию и снова запусти тот же код. Поскольку строка уже существует, оператор select найдет ее, и вы вернете свой объект.

Вы можете увидеть здесь объяснение стратегий для оптимистичной и пессимистической блокировки с помощью спящего режима здесь: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/transactions.html

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

• поиск существующего объекта по имени. если найдут, верни
• start nested (separate) transaction
  • try to insert new object
  • совершить вложенную транзакцию
• поймать любой сбой из вложенной транзакции, если что-либо, кроме нарушения ограничения, повторно бросить
• в противном случае найдите существующий объект по имени и верните его

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

Что ж, вот один из способов сделать это, но он подходит не для всех ситуаций.

• В Foo удалите атрибут "unique = true" на name. Добавьте метку времени, которая обновляется при каждой вставке.
• В findOrCreate() не утруждайте себя проверкой существования сущности с данным именем — просто каждый раз вставляйте новую.
• При поиске экземпляров Foo по name может быть 0 или более экземпляров с заданным именем, поэтому вы просто выбираете самый новый.

Преимущество этого метода в том, что он не требует блокировки, поэтому все должно работать довольно быстро. Недостатком является то, что ваша база данных будет завалена устаревшими записями, поэтому вам, возможно, придется что-то делать в другом месте, чтобы с ними справиться. Кроме того, если другие таблицы ссылаются на Foo по id, то это испортит эти отношения.

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

Я бы попробовал следующую стратегию:

А. Начать основную транзакцию (в момент времени 1)
B. Начать подтранзакцию (во время 2)

Теперь любой объект, созданный после времени 1, не будет виден в основной транзакции. Итак, когда вы делаете

С. Создайте новый объект состояния гонки, зафиксируйте подтранзакцию
D. Обработайте конфликт, запустив новую подтранзакцию (в момент времени 3) и получив объект из запроса (подтранзакция из точки B теперь выходит за рамки).

верните только первичный ключ объекта, а затем используйте EntityManager.getReference(..) для получения объекта, который вы будете использовать в основной транзакции. В качестве альтернативы начните основную транзакцию после D; мне не совсем ясно, сколько условий гонки у вас будет в вашей основной транзакции, но вышеизложенное должно учитывать n раз BCD в «большой» транзакции.

Обратите внимание, что вы можете захотеть использовать многопоточность (один поток на ЦП), и тогда вы, вероятно, сможете значительно уменьшить эту проблему, используя общий статический кеш для таких конфликтов, и пункт 2 можно оставить «оптимистичным», т.е. .find(..) сначала.

Изменить: для новой транзакции вам нужен вызов метода интерфейса EJB, аннотированный типом транзакции REQUIRES_NEW.

Изменить: Дважды проверьте, что getReference(..) работает так, как я думаю.