Hibernate-バッチ更新が更新から予期しない行数を返しました：0実際の行数：0が必要です：1

次の休止状態エラーが発生します。問題の原因となっている機能を特定できます。残念ながら、関数にはいくつかのDB呼び出しがあります。hibernateがトランザクションの最後にセッションをフラッシュするため、問題を引き起こす行を見つけることができません。下記の休止状態エラーは一般的なエラーのように見えます。どのBeanが問題の原因であるかについても言及されていません。この休止状態のエラーを知っている人はいますか？

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構成で、hibernate.show_sqlをtrueに設定します。これにより、実行されて問題の原因となったSQLが表示されます。
• SpringとHibernateのログレベルをDEBUGに設定します。これにより、どの行が問題の原因であるかについてより良いアイデアが得られます。
• Springでトランザクションマネージャーを構成せずに問題を再現する単体テストを作成します。これにより、問題のコード行をよりよく理解できるはずです。

お役に立てば幸いです。

まったく存在しないIDでレコードを削除するときに、同じ例外が発生しました。更新または削除するレコードが実際にDBに存在することを確認してください

解決策：idプロパティのHibernateマッピングファイルで、ジェネレータークラスを使用する場合、そのプロパティには、setterメソッドを使用して値を明示的に設定しないでください。

Idプロパティの値を明示的に設定すると、上記のエラーが発生します。これをチェックして、このエラーを回避します。またはマッピングファイルでフィールドgenerator = "native"または "incremental"に言及し、データベースでマップされたテーブルがauto_incrementedではない場合、エラーが表示されます解決策：データベースに移動し、テーブルを更新してauto_incrementを設定します

これは、特定のIDをいくつかのオブジェクトに割り当て（テスト）ていて、それらをデータベースに保存しようとしたときに、偶然偶然起こりました。問題は、データベースにオブジェクトのIDを設定するための特定のポリシーがあることでした。ただ、していないあなたは、Hibernateのレベルでポリシーを持っている場合はIDを割り当てます。

私の場合、2つの類似したケースでこの例外が発生しました。

• アノテーションが付けられたメソッドで@Transactional、別のサービスへの呼び出しがありました（応答が長い）。メソッドはエンティティの一部のプロパティを更新します（メソッドの後、エンティティはデータベースにまだ存在します）。2回目にトランザクションメソッドを終了するときに、ユーザーがメソッドを2回リクエストした場合（最初は機能しないと考えているため）、Hibernateはトランザクションの最初からすでに状態を変更したエンティティを更新しようとします。Hibernateが状態のエンティティを検索し、同じエンティティを見つけたが、最初のリクエストによってすでに変更されているため、エンティティを更新できないため、例外がスローされます。GITの対立のようなものです。
• エンティティを更新する（およびプラットフォームを監視するための）自動要求（および数秒後の手動ロールバック）がありました。しかし、このプラットフォームはすでにテストチームによって使用されています。テスターが自動リクエストと同じエンティティで（100分の1ミリ秒以内）テストを実行すると、例外が発生します。前のケースと同様に、2番目のトランザクションを終了すると、以前にフェッチしたエンティティはすでに変更されています。

結論：私の場合、コードで見つけることができる問題ではありませんでした。この例外は、データベースから最初にフェッチされたエンティティが現在のトランザクション中に変更されたことが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

問題は、DBテーブルをテストする際に、テーブルの主キーごとに1つのエントリがあったことです。しかし、ステージングDBでは、同じ主キーに対して複数のエントリがありました。（DBのステージングに問題があります。テーブルには主キー制約がなく、複数のエントリがありました。）

そのため、更新操作のたびに失敗します。単一のレコードを更新しようとし、更新カウントが1になることを期待しますが、同じ主キーのテーブルに3つのレコードがあったため、結果更新カウントは3を検出します。予測更新カウントと実際の結果更新カウントが一致しなかったため、例外をスローしてロールバックします。

その後、重複する主キーを持つすべてのレコードを削除し、主キー制約を追加しました。正常に動作しています。

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

実際の行数：0 //更新
するレコードが見つからないことを意味します：0 // レコードが見つからないため、更新は
期待されていません：1 //データベーステーブルにキーがあるレコードが少なくとも1つ必要です。

ここでの問題は、クエリがいくつかのキーのレコードを更新しようとしていることですが、Hibernateはキーを持つレコードを見つけられませんでした。

ジュリアスは更新が削除されてその子を持つオブジェクトに発生したときにこの問題が発生したと言います。（おそらく、父オブジェクト全体の更新が必要であり、時には子を削除して父親に再挿入することを好む（新旧は問題ではない）とともに、父親がそのほかのプレーンフィールド）したがって、これが機能するためには、（トランザクション内で）childrenList.clear()子を削除します（子をループしないで、いくつかchildDAO.delete(childrenList.get(i).delete()))を設定してそれぞれを削除します） @OneToMany(cascade = CascadeType.XXX ,orphanRemoval=true)父オブジェクトの側に。次に、親を更新します（fatherDAO.update（father））。（すべての父親オブジェクトについて繰り返す）その結果、子供は父親へのリンクを削除され、フレームワークによって孤児として削除されます。

この問題は、1対多の関係で発生しました。

マスターのhibernate hbmマッピングファイルに、セットタイプの配置を持つオブジェクトが追加されcascade="save-update"、正常に動作しました。

これがないと、デフォルトでhibernateは存在しないレコードを更新しようとし、そうすることで代わりに挿入します。

またUPDATE、PRIMARY KEYを試行したときにも発生する可能性があります。

同じ問題が発生し、自動インクリメントの主キーが原因でこれが発生する可能性があることを確認しました。この問題を解決するには、自動インクリメント値をデータセットに挿入しないでください。主キーなしでデータを挿入します。

このエラーを取得する別の方法は、コレクションにnullアイテムがある場合です。

同じオブジェクトを削除してから同じオブジェクトを再度更新しようとすると、削除後にこれが使用されます

session.clear（）;

これは私にも起こりました。IDがLongで、ビューから値0を受け取っていたため、データベースに保存しようとしたときにこのエラーが発生したため、IDをnullに設定して修正しました。

として注釈が付けられ@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マネージドBeanを次のように宣言した場合に発生します。

@RequestScoped;

次のように宣言する必要があるとき

@SessionScoped;

よろしく;

データベースに存在しないIDのオブジェクトを更新しようとしたときに、このエラーが発生しました。私の間違いの理由は、クライアント側のオブジェクトのJSON表現に「id」という名前のプロパティを手動で割り当てたため、サーバー側でオブジェクトを逆シリアル化すると、この「id」プロパティがインスタンス変数を上書きするためです（ 「id」とも呼ばれます）Hibernateが生成するはずでした。したがって、Hibernateを使用して識別子を生成する場合は、名前の衝突に注意してください。

私も同じ挑戦に出くわしました。私の場合、を使用して、存在していなかったオブジェクトも更新していましたhibernateTemplate。

実際、私のアプリケーションでは、更新するDBオブジェクトを取得していました。そして、その値を更新しているときに、誤ってIDも更新しました。それを更新して、前述のエラーに遭遇しました。

hibernateTemplateCRUD操作に使用しています。

すべての回答を読んだ後、休止状態の逆の属性について話す人はいませんでした。

私の意見では、逆のキーワードが適切に設定されているかどうかをマッピングで確認する必要もあります。逆キーワードは、関係を維持する所有者を定義するために作成されます。更新および挿入の手順は、この属性によって異なります。

次の2つのテーブルがあるとします。

principal_table、middle_table

1対多の関係で。hiberntateマッピングクラスは、それぞれPrincipalとMiddleです。

したがって、Principalクラスには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>
    ...

逆が「true」に設定されている場合、「中間」クラスが関係の所有者であることを意味するため、プリンシパルクラスは更新されません関係をし。

したがって、更新手順は次のように実装できます。

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の根本的な原因を発見しました。

実際、1つの休止状態のセッションで行を2回削除していました。以前はojdbc6 libを使用していましたが、このバージョンでは問題ありませんでした。

しかし、odjc7またはojdbc8にアップグレードすると、レコードを2回削除すると例外がスローされました。2回削除するコードにバグがありましたが、それはojdbc6では明らかではありませんでした。

次のコードで再現できました。

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

最初のフラッシュでは、休止状態がデータベースに変更を加えます。2回目のフラッシュ中に、休止状態はセッションのオブジェクトを実際のテーブルのレコードと比較しますが、レコードを見つけることができなかったため、例外が発生しました。

この問題は主に、実行中のセッションによってすでにメモリにフェッチされているオブジェクトを保存または更新しようとしたときに発生します。セッションからオブジェクトをフェッチし、データベースで更新しようとすると、この例外がスローされる場合があります。

私はsession.evict（）;を使用しました。最初にhibernateに保存されているキャッシュを削除する場合、またはデータを失うリスクを負いたくない場合は、データを保存する別のオブジェクトを作成することをお勧めします。

     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();
    }

Hibernate 5.4.1およびHHH-12878の問題

Hibernate 5.4.1より前のリリースでは、楽観的ロック失敗の例外（例：StaleStateExceptionまたはOptimisticLockException）には失敗したステートメントが含まれていませんでした。

HHH-12878楽観的ロックの例外をスローする場合、JDBCのように、問題は、休止状態を改善するために作成されたPreparedStatement実装がうまくとして記録されます。

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;
    }
}

次の3つの構成プロパティを使用して、JDBCバッチ処理を有効にします。

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メソッドを使用して2番目の遷移を実行します。

2番目のトランザクションは最初のを変更する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=?

したがって、この改善を利用するには、Hibernate 5.4.1以降にアップグレードする必要があります。

これは、ネイティブSQLクエリを使用してデータセットの何かを変更したが、同じデータセットの永続オブジェクトがセッションキャッシュに存在する場合に発生しました。session.evict（yourObject）;を使用します。

Hibernateはセッションからオブジェクトをキャッシュします。複数のユーザーがオブジェクトにアクセスして変更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を使用して1つのレコードを手動で挿入しようとしましたが、ここで問題が明らかになりました。SQL挿入クエリは0挿入を返します。また、nullを返すため、この問題を引き起こすトリガー関数があります。新しいものを返すように設定するだけです。そして最後に私は問題を解決しました。

どんな体にも役立つことを願っています。

私が誤ってID列をマッピングしたため、このエラーが発生しましたId(x => x.Id, "id").GeneratedBy.**Assigned**();

を使用して解決した問題 Id(x => x.Id, "id").GeneratedBy.**Identity**();

これは、BeanクラスでID宣言が欠落しているために起こります。

私の場合、ストアドプロシージャの1つがすべてのCPUを消費しているため、データベースに問題があり、DB応答時間が長くなりました。これが殺されると問題は解決しました。