Строка была обновлена ​​или удалена другой транзакцией (или сопоставление несохраненных значений было неверным).

Пессимистическая блокировка, как правило, не рекомендуется, и это очень дорого с точки зрения производительности на стороне базы данных. Проблема, о которой вы упомянули (часть кода), не совсем ясна, например:

• Если к вашему коду одновременно обращаются несколько потоков.
• Как вы создаете объект session (не уверен, что используете Spring)?

Hibernate Объекты сеанса НЕ являются потокобезопасными. Поэтому, если есть несколько потоков, обращающихся к одному и тому же сеансу и пытающихся обновить один и тот же объект базы данных, ваш код потенциально может оказаться в подобной ситуации с ошибкой.

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

ИЗМЕНИТЬ:

Есть способ использовать пессимистическую блокировку в Hibernate. Перейдите по этой ссылке. Но, кажется, есть некоторые проблемы с этим механизмом. Однако я обнаружил ошибку в спящем режиме (HHH-5275). Сценарий, упомянутый в ошибке, выглядит следующим образом:

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

Это очень близко к тому, с чем вы столкнулись. Пожалуйста, попробуйте это, если это не сработает, единственный способ, который я могу придумать, это использовать Собственные SQL-запросы, где вы можете достичь пессимистическая блокировка в базе данных postgres с SELECT FOR UPDATE запросом.

Я знаю, что это старый вопрос, но некоторые из нас все еще задаются им и смотрят на небо, задаваясь вопросом, как это сделать. Вот одна из проблем, с которыми я столкнулся.

У нас есть менеджер очередей, который опрашивает данные и отдает их обработчикам для обработки. Чтобы избежать повторного захвата одних и тех же событий, администратор очередей блокирует запись в базе данных с состоянием LOCKED.

    void poll() {
        record = dao.getLockedEntity();
        queue(record);
    }

этот метод не был транзакционным, но dao.getLockedEntity() был транзакционным с REQUIRED.

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

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

    @Transactional(propagation=Propagation.REQUIRED, readOnly=false)
    void poll() {
        record = dao.getLockedEntity();
        queue(record);              
    }

Таким образом, запись была поставлена ​​в очередь еще до того, как транзакция в dao.getLockedEntity() была зафиксирована (она использует ту же транзакцию метода опроса), и объект был изменен ниже обработчиками (разными потоками) к тому времени, когда транзакция метода poll() была зафиксирована.

Мы исправили проблему, и теперь все выглядит хорошо.

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

С уважением, Люйю

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

Вероятно, вы хотите, чтобы ваш код выглядел примерно так:

    @Transactional
    public void test(String id, String subject) {
       Email email = getEmailById(id);
       email.setSubject(subject);
       updateEmail(email);
    }

У меня была эта проблема в моем проекте.

После того, как я реализовал оптимистическую блокировку, я получил такое же исключение. Моя ошибка заключалась в том, что я не удалил сеттер поля, которое стало @Version. Поскольку сеттер вызывался в пространстве java, значение поля больше не соответствовало значению, сгенерированному БД. Таким образом, в основном поля версии больше не совпадали. На тот момент любая модификация сущности приводила к:

org.hibernate.StaleObjectStateException: строка была обновлена ​​или удалена другой транзакцией (или сопоставление несохраненных значений было неправильным)

Я использую H2 в БД памяти и Hibernate.

Это исключение, вероятно, вызвано оптимистичной блокировкой (или ошибкой в ​​вашем коде). Вы, вероятно, используете его, не зная. И ваш псевдокод (который следует заменить реальным кодом, чтобы иметь возможность диагностировать проблему) неверен. Hibernate автоматически сохраняет все изменения, внесенные в прикрепленные объекты. Вы никогда не должны вызывать обновление, слияние или saveOrUpdate для прикрепленного объекта. Просто сделать

Email email = session.get(emailId);
email.setSubject(subject);

Нет необходимости вызывать обновление. Hibernate автоматически сбросит изменения перед фиксацией транзакции.

У меня была та же проблема, и в моем случае проблема отсутствовала и/или неправильная реализация equals для некоторых типов полей в объекте объекта. Во время фиксации Hibernate проверяет ВСЕ объекты, загруженные в сеанс, чтобы проверить, не загрязнены ли они. Если какой-либо из сущностей грязный, спящий режим пытается их сохранить - независимо от того факта, что фактический объект, для которого запрашивается операция сохранения, не связан с другими сущностями.

Загрязнение объекта выполняется путем сравнения каждого свойства данного объекта (с их методами равенства) или UserType.equals, если свойство имеет связанный org.Hibernate.UserType.

Еще одна вещь, которая меня удивила, заключалась в том, что в моей транзакции (используя аннотацию Spring @Transactional) я имел дело с одним объектом. Hibernate жаловался на какой-то случайный объект, не связанный с сохранением этого объекта. Я понял, что есть самая внешняя транзакция, которую мы создаем на уровне контроллера REST, поэтому область сеанса слишком велика, и, следовательно, все объекты, когда-либо загруженные как часть обработки запроса, проверяются на загрязнение.

Надеюсь, это поможет кому-то, когда-нибудь.

Спасибо тряпки

проверьте, существует ли объект в БД или нет, если он существует, получите объект и обновите его:

if (getEntityManager().contains(instance)) {
    getEntityManager().refresh(instance);
    return instance;
}

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

if (....) {
    } else if (null != identity) {
        E dbInstance = (E) getEntityManager().find(instance.getClass(), identity);
        return dbInstance;
    }

У меня возникла одна и та же проблема в другом контексте моего проекта, и есть разные сценарии, такие как

 - object is accessed from various source like (server side and client)
 - without any interval accessing the same object from a different place

В первом случае

Когда я выдаю кал сервера, прежде чем сохранить этот объект, их один вызов из js и попытка сохранить и другое место, я понял, что вызов js происходит два, три раза (я думаю, что проблема привязки вызова вызывает проблему)

я решил

e.preventDefault()

Второй случай,

object.lock()

Я тоже получал такое исключение, но проблема была в моем идентификаторе Entity. Я использую UUID, и есть некоторые проблемы в том, как с ними работает Spring. Поэтому я просто добавил эту строку в свой идентификатор объекта, и он начал работать:

@Column(columnDefinition = "BINARY(16)")

Здесь вы можете найти немного больше информации.

На всякий случай, если кто-то проверил эту тему и столкнулся с такой же проблемой, как у меня...

Строка была обновлена ​​или удалена другой транзакцией (или сопоставление несохраненных значений было неверным).

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

Я передавал ключ вручную, а также указал генератор GUID в сопоставлении...

И спящий режим генерирует для меня точно такую ​​​​же ошибку, поэтому, как только я удалил GUID и оставил поле пустым, все прошло нормально.

Этот ответ может не помочь вам, но поможет кому-то вроде меня, который только что просмотрел вашу тему из-за той же ошибки.

Эта ошибка возникла у меня, когда я пытался обновить одну и ту же строку из двух разных сеансов. Я обновил поле в одном браузере, в то время как второй был открыт и уже сохранил исходный объект в своем сеансе. Когда я попытался обновить этот второй «устаревший» сеанс, я получаю сообщение об ошибке устаревшего объекта. Чтобы исправить это, я повторно загружаю свой объект для обновления из базы данных, прежде чем установить значение для обновления, а затем сохраняю его как обычно.

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

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

После изменения ключа на LocalDateTime ошибка исчезла. Кроме того, обновление отдельных строк также стало работать — раньше не удалось найти строку для обновления, и тестирование этой отдельной проблемы на самом деле привело меня к моим выводам относительно сопоставления первичного ключа.

Не устанавливайте Id для объекта, который вы сохраняете, так как Id будет сгенерирован автоматически.

У меня были проблемы с одной и той же ошибкой в ​​​​более чем одном проекте Spring. Для меня общим решением было разделить мой метод службы, чтобы каждое действие INSERT, UPDATE и DELETE получило собственный метод с @Transactional. Я думаю, что эта проблема связана с внутренним управлением Spring, где взаимодействие с базой данных выполняется в конце метода, и, по моему мнению, это точка, в которой срабатывает исключение.

Обновление и дополнительные решения.

Моя проблема заключалась в том, что я запросил объект @Entity Class и изменил значение, не сохранив его, потому что, строго говоря, он был обновлен другим запросом (вне области действия), но поскольку этот объект был внутренним для сеансы в карте теперь имели другое значение, следующий запрос блокировался с этим сообщением.

Поэтому я создал переменную и сохранил там новые значения, а затем отправил их в UpdateQuery, чтобы Hibernate не регистрировал несохраненные изменения и строку можно было обновить. Hibernate, похоже, отправляет оператор блокировки в базу данных каждый раз, когда объект класса @Entity изменяется или, по крайней мере, локально пробивает строку по первичному ключу.

У меня была такая же проблема в моем проекте Grails. Ошибка заключалась в том, что я перезаписывал метод получения поля коллекции. Это всегда возвращало новую версию коллекции в другом потоке.

class Entity {
    List collection

    List getCollection() {
        return collection.unique()
    }
}

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

class Entity {
    List collection

    List getUniqueCollection() {
        return collection.unique()
    }
}

Чтобы предотвратить StaleObjectStateException, в файле hbm напишите следующий код:

<timestamp name="lstUpdTstamp" column="LST_UPD_TSTAMP" source="db"/>

Сначала проверьте свой импорт, когда вы используете сеанс, транзакция должна быть org.hibernate и удалите аннотацию @Transactinal. и самое главное в классе Entity, если вы использовали @GeneratedValue(strategy=GenerationType.AUTO) или любой другой, то во время создания объекта модели/создания объекта объекта не следует создавать идентификатор. Окончательный вывод: если вы хотите, чтобы идентификатор пропуска был подан, то есть PK, удалите @GeneratedValue из класса объектов.

У меня была эта проблема в одном из моих приложений, теперь я знаю, что это старая тема, но вот мое решение; Изучив данные внутри отладчика, я понял, что JVM на самом деле не загружала их должным образом, когда Hibernate пытался обновить базу данных (что на самом деле делается в другом потоке), поэтому я добавил ключевое слово «volatile» в каждое поле. сущностей. У него есть некоторые проблемы с производительностью, но вместо того, чтобы бросать тяжелые объекты...