Массовое обновление в режиме гибернации приводит к появлению запросов, для завершения которых требуется всегда - PullRequest
1 голос
/ 10 декабря 2010

Article сущность является подклассом сущности Product. Стратегия наследования для них - joined. Article#flag - это логический атрибут, который я хочу установить false для всех статей. Следовательно, я делаю

Query query = entityManager.createQuery("update Article set flag=:flagValue");
query.setParameter("flagValue", false);
query.executeUpdate();

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

insert into HT_article select article0_.id as id from schema.article article0_ inner join schema.product article0_1_ on article0_.id=article0_1_.id

update schema.article set flag=0 where (id) IN (select id from HT_article)

Фактический оператор обновления требует «навсегда» для завершения и блокирует уязвимые статьи, вызывая тем самым исключения блокировки в других транзакциях. Под вечностью я подразумеваю более часа для 130000 статей.

Чем объясняется такое поведение и как я могу его решить? Помимо выполнения собственного запроса, я имею в виду ...

Обновление 2011-05-12: это ужасно медленно, потому что запрос медленно, я подал ошибку для этого -> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5905

Ответы [ 2 ]

1 голос
/ 12 мая 2015

Я использую InheritanceType.JOINED hibernate и столкнулся с аналогичной проблемой, когда hibernate вставлял в временную таблицу и занимал целую вечность, чтобы удалить объекты. Я использовал createQuery и executeUpdate, чтобы удалить записи, которые вызвали проблему. Начал использовать session.delete(entity), который решил проблему для меня.

0 голосов
/ 11 мая 2011

Поскольку вы используете InheritanceType.JOINED, у Hibernate нет другого выбора, кроме как объединить подкласс и его базовый класс.

Если бы вы переключились на InheritanceType.TABLE_PER_CLASS (http://openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/docs/manual/jpa_overview_mapping_inher.html), вы бы этого избежали и вернули себе производительность. Но я уверен, что вы используете JOINED по причине: - (

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...