Строка StaleObjectstateException была обновлена ​​или удалена

Вы каким-то образом неправильно используете Hibernate, из-за чего он думает, что вы обновляете или удаляете объекты из базы данных.

Вот почему вызов flush() вызывает исключение.

Одна из возможностей: вы неправильно "делитесь" сеансом или сущностями через поля-члены вашего сервлета или контроллера. Это основная причина, по которой «синхронизация» изменит ваши симптомы ошибки. Короткое решение: никогда не делайте этого. Сеансы и объекты не должны и не должны работать таким образом — каждый запрос должен обрабатываться независимо.

Другая возможность: unsaved-value по умолчанию равен 0 для полей PK "int". Вместо этого вы можете ввести их как «Целое число», если вы действительно хотите использовать 0 в качестве допустимого значения PK.

Третье предложение: явно используйте сеанс Hibernate, научитесь писать простой правильный код, который работает, а затем загрузите исходный код Java для библиотек Hibernate/Spring, чтобы вы могли прочитать и понять, что эти библиотеки на самом деле делают для вас.

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

org.hibernate.StaleObjectStateException: строка была обновлена ​​или удалена другой транзакцией (или сопоставление несохраненных значений было неверным): [com.rc.model.mexp.MerchantAccount#59132]

В нашем случае оказалось, что отображение было неверным; у нас было type="text" в отображении для одного поля, которое было типом среднего текста в базе данных, и кажется, что Hibernate действительно ненавидит это, по крайней мере, при определенных обстоятельствах. Мы полностью убрали спецификацию типа из сопоставления для этого поля, и проблема была решена.

Теперь странно то, что в нашей производственной среде с предположительно проблематичным отображением мы НЕ получаем это исключение. Кто-нибудь знает, почему это может быть? Мы используем одну и ту же версию MySQL — «5.0.22-log» (я не знаю, что означает «-log») — в средах разработки и производства.

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

Используйте двунаправленное сопоставление с inverse=true между родительским объектом и дочерним объектом, чтобы изменение в родительском или дочернем объекте правильно распространялось на другой конец отношения.

Добавьте поддержку оптимистической блокировки с помощью столбца TimeStamp или Version.

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

Наконец, если и только если ничего не работает: снова загрузите родительский элемент с помощью Id (у вас это уже есть) и заполните измененные данные, а затем обновите.

Жизнь будет хороша! :)

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

Во-первых, убедитесь, что все ваши методы снабжены аннотациями @Transaction(required=true) // you'll have to look up the exact syntax.

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