Hibernate - Пакетне оновлення повернуло несподіваний кількість рядків із оновлення: 0 фактичний кількість рядків: 0 очікувано: 1

Я отримую наступну сплячу помилку. Я можу визначити функцію, яка викликає проблему. На жаль, у функції є кілька викликів БД. Я не можу знайти рядок, який спричиняє проблему, оскільки сплячий режим змиває сеанс наприкінці транзакції. Згадана нижче помилка в сплячому режимі виглядає як загальна помилка. Навіть не згадується, який Бін викликає проблему. Хтось знайомий з цією сплячою помилкою?

org.hibernate.StaleStateException: Batch update returned unexpected row count from update: 0 actual row count: 0 expected: 1
        at org.hibernate.jdbc.BatchingBatcher.checkRowCount(BatchingBatcher.java:93)
        at org.hibernate.jdbc.BatchingBatcher.checkRowCounts(BatchingBatcher.java:79)
        at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
        at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
        at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
        at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
        at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985)
        at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333)
        at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
        at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:584)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransacti
onManager.java:500)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManag
er.java:473)
        at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(Transaction
AspectSupport.java:267)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)

Без коду та відображень для ваших трансакцій дослідити проблему буде неможливо.

Однак, щоб краще вирішити, що викликає проблему, спробуйте наступне:

• У конфігурації сплячки встановіть для hibernate.show_sql значення true. Це повинно показати вам SQL, який виконується, і викликає проблему.
• Встановіть рівні журналу для Spring and Hibernate на DEBUG, це знову дасть вам кращі уявлення про те, який рядок викликає проблему.
• Створіть тест одиниці, який повторює проблему, не налаштовуючи диспетчера транзакцій навесні. Це повинно дати вам кращі уявлення про правопорядковий рядок коду.

Сподіваюся, що це допомагає.

Я отримав той самий виняток під час видалення запису Id, який взагалі не існує. Тому перевірте, що запис, який ви оновлюєте / видаляєте, фактично існує в БД

Рішення: У файлі відображення Hibernate для властивості id, якщо ви використовуєте будь-який клас генератора, для цього властивості не слід встановлювати значення явно за допомогою методу setter.

Якщо ви встановите значення властивості Id явно, це призведе до помилки вище. Перевірте це, щоб уникнути цієї помилки. або Це повідомлення про помилку, коли ви згадуєте у картографічному файлі генератор поля = "рідний" або "інкрементальний", а у вашій ДАТАБАСІ відображена таблиця не автоматично підвищена

Це сталося зі мною випадково, коли я призначав певні ідентифікатори деяким об’єктам (тестування), а потім намагався зберегти їх у базі даних. Проблема полягала в тому, що в базі даних була специфічна політика встановлення ідентифікаторів об’єктів. Просто не призначайте ідентифікатор, якщо у вас є політика на рівні сну.

У моєму випадку я потрапив до цього винятку у двох подібних випадках:

• У анотаційному методі у @Transactionalмене був дзвінок до іншої служби (з тривалим часом відповіді). Метод оновлює деякі властивості сутності (після методу сутність все ще існує в базі даних). Якщо користувач два рази запитує метод (оскільки він вважає, що він не працює в перший раз) при виході з транзакційного методу вдруге, Hibernate намагається оновити сутність, яка вже змінила стан з початку транзакції. Коли Hibernate шукає суб'єкт у державі і знайшов ту саму сутність, але вже змінена першим запитом, вона видає виняток, оскільки не може оновити сутність. Це як конфлікт у GIT.
• У мене були автоматичні запити (для моніторингу платформи), які оновлюють об'єкт (і відкат вручну через кілька секунд). Але ця платформа вже використовується тестовою командою. Коли тестер виконує тест у тій самій суті, що і автоматичні запити (в межах однієї сотої мілісекунди), я отримую виняток. Як і в попередньому випадку, при виході з другої транзакції раніше отриманий суб'єкт господарювання вже змінився.

Висновок: у моєму випадку це не проблема, яку можна знайти в коді. Цей виняток видається, коли Hibernate виявляє, що суб'єкт, який вийшов із бази даних, змінився під час поточної транзакції , тому він не може передати його в базу даних, оскільки Hibernate не знає, що є правильною версією сутності: такою, яка є поточною отримання транзакцій на початку; або той, що вже зберігається в базі даних.

Рішення: щоб вирішити проблему, вам доведеться пограти з Hibernate LockMode, щоб знайти той, який найкраще відповідає вашим вимогам.

Я щойно зіткнувся з цією проблемою і дізнався, що я видаляю запис і намагаюся згодом оновити його в режимі Hibernate.

Це може статися, коли тригери виконують додаткові запити DML (модифікація даних), які впливають на кількість рядків. Моє рішення було додати наступне у верхній частині мого тригера:

SET NOCOUNT ON;

Я стикався з тим же питанням. Код працював у середовищі тестування. Але це не працює в постановочному середовищі.

org.hibernate.jdbc.BatchedTooManyRowsAffectedException: Batch update returned unexpected row count from update [0]; actual row count: 3; expected: 1

Проблема полягала в тому, що таблиця мала один запис для кожного первинного ключа в тестуванні таблиці БД. Але в постановці БД було кілька записів для одного і того ж первинного ключа. (Проблема полягає в постановці БД. У таблиці не було обмежень для первинного ключа, також було багаторазове введення.)

Тому щоразу, коли операція оновлення стає невдалою. Він намагається оновити один запис і розраховує отримати кількість оновлень як 1. Але оскільки в таблиці було 3 записи для одного і того ж первинного ключа, кількість оновлених результатів виявляється 3. Оскільки очікуваний кількість оновлень і фактичний підсумок оновлення результатів не збігаються , Він кидає виняток і відкочується назад.

Після цього я видалив усі записи, які мають повторюваний первинний ключ, та додав обмеження первинного ключа. Це прекрасно працює.

Hibernate - Batch update returned unexpected row count from update: 0 actual row count: 0 expected: 1

фактична кількість рядків: 0 // означає, що запис не знайдено для оновлення
оновлення: 0 // означає, що запис не знайдено, тому нічого не
очікується оновлення : 1 // означає очікуваний принаймні 1 запис із ключем у db таблиці.

Тут проблема полягає в тому, що запит, який намагається оновити запис для якогось ключа, але в сплячому режимі не знайшов жодної записи з ключем.

Як каже Юлій, це відбувається, коли оновлення відбувається на об'єкті, який видаляє своїх дітей. (Можливо, тому, що була необхідність оновлення для всього Об'єкта Батька, а іноді ми вважаємо за краще видалити дітей і повторно вставити їх у Отця (нові, старі, не важливо) разом з будь-якими іншими оновленнями, які батько міг би мати на будь-якому з інші його прості поля) Отже ... для того, щоб це працювало, видаліть дітей (в рамках транзакції), зателефонувавши childrenList.clear()(Не перетворюйте цикл через дітей і видаліть кожного з деякими childDAO.delete(childrenList.get(i).delete()))та налаштуваннями @OneToMany(cascade = CascadeType.XXX ,orphanRemoval=true)на стороні об'єкта Батька. Потім оновіть батька (očeDAO.update (батько)). (Повторіть для кожного батька). Результат полягає в тому, що у дітей знімається зв'язок з батьком, а потім їх видаляють як сиріт за рамками.

Я зіткнувся з цією проблемою, коли у нас було багато-багато стосунків.

У гібернаційний файл відображення hbm для ведучого, для об'єкта з набором типів розташування додано, cascade="save-update"і він прекрасно працював.

Без цього сплячий режим за замовчуванням намагається оновити для неіснуючої записи і, роблячи це, замість цього вставляє.

Це також може статися , коли ви намагаєтеся UPDATEз PRIMARY KEY .

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

Ще один спосіб отримати цю помилку - якщо у колекції є нульовий елемент.

це трапляється, коли ви намагаєтесь видалити той самий об’єкт, а потім знову оновити той самий об’єкт, використовуйте це після видалення

session.clear ();

Це трапилося і зі мною, тому що я мав свій ідентифікатор як Long, і я отримував від подання значення 0, і коли я намагався зберегти в базі даних, я отримав цю помилку, то я виправив її, встановивши id на нуль.

Я зіткнувся з цим питанням, коли я вручну починав і здійснював транзакції всередині методу, позначеного як @Transactional. Я вирішив проблему, виявивши, чи існує вже активна транзакція.

//Detect underlying transaction
if (session.getTransaction() != null && session.getTransaction().isActive()) {
    myTransaction = session.getTransaction();
    preExistingTransaction = true;
} else {
    myTransaction = session.beginTransaction();
}

Тоді я дозволив Spring впоратися із здійсненням транзакції.

private void finishTransaction() {
    if (!preExistingTransaction) {
        try {
            tx.commit();
        } catch (HibernateException he) {
            if (tx != null) {
                tx.rollback();
            }
            log.error(he);
        } finally {
            if (newSessionOpened) {
                SessionFactoryUtils.closeSession(session);
                newSessionOpened = false;
                maxResults = 0;
            }
        }
    }
}

Це відбувається, коли ви оголосили JSF Managed Bean як

@RequestScoped;

коли ви повинні оголосити як

@SessionScoped;

З повагою;

Я отримав цю помилку, коли намагався оновити об’єкт з ідентифікатором, який не існував у базі даних. Причиною моєї помилки було те, що я вручну призначив властивість з ім'ям "id" для клієнтського JSON-представлення об'єкта, а потім при десеріалізації об'єкта на стороні сервера ця властивість 'id' замінить змінну екземпляра ( також називали "id"), який повинен був створити сплячий режим. Тому будьте обережні, називаючи зіткнення, якщо ви використовуєте Hibernate для створення ідентифікаторів.

Я також зіткнувся з тим же викликом. У моєму випадку я оновлював об'єкт, який навіть не існував, використовуючиhibernateTemplate .

Насправді у своїй програмі я отримував об’єкт БД для оновлення. Оновляючи його значення, я також помилково оновив його ідентифікатор і продовжував його оновлювати і натрапив на зазначену помилку.

Я використовую hibernateTemplateдля операцій CRUD.

Прочитавши всі відповіді, не знайшлося нікого, щоб поговорити про зворотній атрибут сну.

На мою думку, ви також повинні переконатись у відображенні ваших стосунків, чи правильно встановлено зворотне ключове слово. Зворотний ключове слово створюється для визначення того, на якій стороні є власник для підтримки відносин. Процедура оновлення та вставки змінюється відповідно до цього атрибуту.

Припустимо, у нас є дві таблиці:

головна таблиця , середня таблиця

з відносинами одного до багатьох . Класи зі сплячого сну в гибернтаті - це головний і середній відповідно.

Отже, клас Principal має SET об'єктів Middle . Файл відображення xml має бути таким:

<hibernate-mapping>
    <class name="path.to.class.Principal" table="principal_table" ...>
    ...
    <set name="middleObjects" table="middle_table" inverse="true" fetch="select">
        <key>
            <column name="PRINCIPAL_ID" not-null="true" />
        </key>
        <one-to-many class="path.to.class.Middel" />
    </set>
    ...

Оскільки обернено встановлено значення "вірно", це означає, що "Середній" клас є власником відносин, тому клас Основний НЕ ОНОВЛЮЄТЬСЯ відношення.

Тож процедура оновлення може бути реалізована так:

session.beginTransaction();

Principal principal = new Principal();
principal.setSomething("1");
principal.setSomethingElse("2");


Middle middleObject = new Middle();
middleObject.setSomething("1");

middleObject.setPrincipal(principal);
principal.getMiddleObjects().add(middleObject);

session.saveOrUpdate(principal);
session.saveOrUpdate(middleObject); // NOTICE: you will need to save it manually

session.getTransaction().commit();

Це працювало для мене, але ви можете запропонувати деякі видання, щоб покращити рішення. Таким чином ми всі будемо вчитися.

У нашому випадку ми нарешті з’ясували першопричину StaleStateException.

Насправді ми видаляли ряд два рази за один сплячий режим. Раніше ми використовували ojdbc6 lib, і це було нормально в цій версії.

Але коли ми перейшли до odjc7 або ojdbc8, видалення записів двічі кидало виняток. У нашому коді була помилка, де ми двічі видаляли, але це не було очевидно в ojdbc6.

Ми змогли відтворити цей фрагмент коду:

Detail detail = getDetail(Long.valueOf(1396451));
session.delete(detail);
session.flush();
session.delete(detail);
session.flush();

При першому спалаху сплячий режим переходить і вносить зміни в базу даних. Під час другого флеш-режиму сплячий режим порівнює об'єкт сеансу із фактичним записом таблиці, але не може знайти його, отже, виняток.

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

Я використав session.evict (); щоб спочатку видалити кеш, який зберігається в сплячому режимі, або якщо ви не хочете ризикувати втратою даних, краще зробіть інший об’єкт для зберігання темпу даних.

     try
    {
        if(!session.isOpen())
        {
            session=EmployeyDao.getSessionFactory().openSession();
        }
            tx=session.beginTransaction();

        session.evict(e);
        session.saveOrUpdate(e);
        tx.commit();;
        EmployeyDao.shutDown(session);
    }
    catch(HibernateException exc)
    {
        exc.printStackTrace();
        tx.rollback();
    }

Зимова сплячка 5.4.1 та HHH-12878 випуск

До Hibernate 5.4.1, винятки щодо оптимістичного блокування блокування (наприклад, StaleStateExceptionабо OptimisticLockException) не включали заяву про відмову .

The HHH-12878 був створений для вдосконалення режиму сплячки, щоб при передачі оптимістичного виключення блокування PreparedStatementтакож реєструвалася реалізація JDBC :

if ( expectedRowCount > rowCount ) {
    throw new StaleStateException(
            "Batch update returned unexpected row count from update ["
                    + batchPosition + "]; actual row count: " + rowCount
                    + "; expected: " + expectedRowCount + "; statement executed: "
                    + statement
    );
}

Час тестування

Я створив свою BatchingOptimisticLockingTest у своєму високоефективному сховищі Java Persistence GitHub, щоб продемонструвати, як працює нова поведінка.

По-перше, ми визначимо Postсутність, яка визначає @Versionвластивість, тому активуючи неявний оптимістичний механізм блокування :

@Entity(name = "Post")
@Table(name = "post")
public class Post {

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private Long id;

    private String title;

    @Version
    private short version;

    public Long getId() {
        return id;
    }

    public Post setId(Long id) {
        this.id = id;
        return this;
    }

    public String getTitle() {
        return title;
    }

    public Post setTitle(String title) {
        this.title = title;
        return this;
    }

    public short getVersion() {
        return version;
    }
}

Ми включимо пакетне JDBC, використовуючи наступні 3 властивості конфігурації:

properties.put("hibernate.jdbc.batch_size", "5");
properties.put("hibernate.order_inserts", "true");
properties.put("hibernate.order_updates", "true");

Ми створимо 3 Postоб'єкти:

doInJPA(entityManager -> {
    for (int i = 1; i <= 3; i++) {
        entityManager.persist(
            new Post()
                .setTitle(String.format("Post no. %d", i))
        );
    }
});

І Hibernate виконає пакетну вставку JDBC:

SELECT nextval ('hibernate_sequence')
SELECT nextval ('hibernate_sequence')
SELECT nextval ('hibernate_sequence')

Query: [
    INSERT INTO post (title, version, id) 
    VALUES (?, ?, ?)
], 
Params:[
    (Post no. 1, 0, 1), 
    (Post no. 2, 0, 2), 
    (Post no. 3, 0, 3)
]

Отже, ми знаємо, що дозування JDBC працює чудово.

Тепер давайте повторимо оптимістичне питання блокування:

doInJPA(entityManager -> {
    List<Post> posts = entityManager.createQuery("""
        select p 
        from Post p
        """, Post.class)
    .getResultList();

    posts.forEach(
        post -> post.setTitle(
            post.getTitle() + " - 2nd edition"
        )
    );

    executeSync(
        () -> doInJPA(_entityManager -> {
            Post post = _entityManager.createQuery("""
                select p 
                from Post p
                order by p.id
                """, Post.class)
            .setMaxResults(1)
            .getSingleResult();

            post.setTitle(post.getTitle() + " - corrected");
        })
    );
});

Перша транзакція вибирає всі Postсутності та модифікуєtitle властивості.

Однак перед тим, як перший EntityManagerзмити, ми збираємось виконати другий перехід за допомогоюexecuteSync методу.

Друга транзакція змінює першу Post, тому її versionбуде нарощувати:

Query:[
    UPDATE 
        post 
    SET 
        title = ?, 
        version = ? 
    WHERE 
        id = ? AND 
        version = ?
], 
Params:[
    ('Post no. 1 - corrected', 1, 1, 0)
]

Тепер, коли перша транзакція спробує змити її EntityManager, ми отримаємо OptimisticLockException:

Query:[
    UPDATE 
        post 
    SET 
        title = ?, 
        version = ? 
    WHERE 
        id = ? AND 
        version = ?
], 
Params:[
    ('Post no. 1 - 2nd edition', 1, 1, 0), 
    ('Post no. 2 - 2nd edition', 1, 2, 0), 
    ('Post no. 3 - 2nd edition', 1, 3, 0)
]

o.h.e.j.b.i.AbstractBatchImpl - HHH000010: On release of batch it still contained JDBC statements

o.h.e.j.b.i.BatchingBatch - HHH000315: Exception executing batch [
    org.hibernate.StaleStateException: 
    Batch update returned unexpected row count from update [0]; 
    actual row count: 0; 
    expected: 1; 
    statement executed: 
        PgPreparedStatement [
            update post set title='Post no. 3 - 2nd edition', version=1 where id=3 and version=0
        ]
], 
SQL: update post set title=?, version=? where id=? and version=?

Таким чином, вам потрібно перейти на сплячий режим 5.4.1 або новіший, щоб скористатися цим покращенням.

Це сталося, якщо ви змінили щось у наборі даних, використовуючи нативний запит sql, але збережений об’єкт для того ж набору даних присутній у кеш сесії. Використовуйте session.evict (вашObject);

Спячий режим кешує об’єкти сеансу. Якщо доступ до об'єкта доступний і модифікований більш ніж 1 користувачем, org.hibernate.StaleStateExceptionйого можна перекинути. Це може бути вирішено методом об'єднання / оновлення об'єкта перед збереженням або використанням блокування. Більше інформації: http://java-fp.blogspot.lt/2011/09/orghibernatestalestateexception-batch.html

Один із випадків

SessionFactory sf=new Configuration().configure().buildSessionFactory();
Session session=sf.openSession();

UserDetails user=new UserDetails();

session.beginTransaction();
user.setUserName("update user agian");
user.setUserId(12);
session.saveOrUpdate(user);
session.getTransaction().commit();
System.out.println("user::"+user.getUserName());

sf.close();

Я зіткнувся з цим винятком, і сплячий стан працював добре. Я намагався вставити один запис вручну за допомогою pgAdmin, тут проблема стала зрозумілою. Запит на вставку SQL повертає 0 вставки. і є тригерна функція, яка спричиняє цю проблему, оскільки вона повертається до нуля. тому я маю лише встановити це, щоб повернути нове. і нарешті я вирішив проблему.

сподівання, що допомагає будь-якому організму.

Я отримав цю помилку, оскільки я помилково відобразив IDстовпчик за допомогоюId(x => x.Id, "id").GeneratedBy.**Assigned**();

Проблема вирішена за допомогою Id(x => x.Id, "id").GeneratedBy.**Identity**();

Це трапляється зі мною, оскільки мені не вистачає декларації з ідентифікатором у класі bean

У моєму випадку виникла проблема з базою даних, оскільки одна із збережених програм споживала весь процесор, викликаючи високий час відповіді БД. Як тільки це було вбито питання було вирішено.