繁体   English   中英

Hibernate 与合并的结果不一致和冲突

[英]Hibernate Inconsistent and Conflicting Results with Merge

版本Red Hat Build of Quarkus


  <properties>
    <compiler-plugin.version>3.8.1</compiler-plugin.version>
    <maven.compiler.parameters>true</maven.compiler.parameters>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <quarkus-plugin.version>1.7.5.Final</quarkus-plugin.version>
    <quarkus.platform.artifact-id>quarkus-universe-bom</quarkus.platform.artifact-id>
    <quarkus.platform.group-id>io.quarkus</quarkus.platform.group-id>
    <quarkus.platform.version>1.7.5.Final</quarkus.platform.version>
    <surefire-plugin.version>3.0.0-M5</surefire-plugin.version>
  </properties>

我对这种不一致感到非常困惑,尽管将日志记录设置为最大值,但我所看到的是,与其他项目相比,我的代码在该项目中的表现并不相同。

版本和设置的所有配置都相同。

我有三个 quarkus jax-rs 服务,hibernate-orm 推送到 PostgreSQL。

2 个服务都按预期运行,大约 25 个配置相同的 PUT 端点带有合并支持管理器(下面的代码)。 在这两个工作服务中,日志中的语句显示需要 UPDATE 语句的位置。 但是,第三个(新)服务只是忽略了更改。 它以 200 响应,甚至返回更新的数据,但数据库永远不会更新。

简单实体

@Entity
@Table(name = "applicants")
public class Applicant implements Serializable {

    private static final long serialVersionUID = 6796452320678418766L;

    @Column(name = "applicant_id")
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "applicant_seq")
    public long applicant_id;

    @Column(name = "email", nullable = false, unique = true)
    public String email;
}

@PUT 资源

@PUT
    @Path("{id}")
    public Response update(@PathParam("id") Long id, @Valid Applicant applicant) {
        try {
            Applicant applicantToUpdate = this.manager.findById(id);
            if (applicantToUpdate != null) {
                applicantToUpdate = this.manager.save(applicant);
                if (applicantToUpdate != null) {
                    return Response.ok(applicantToUpdate).build();
                } else {
                    ...
                }
            }
            return Response.status(Response.Status.NOT_FOUND).build();
        } catch (Exception ex) {
            ...
        }
    }

持久性的支持管理器

@Transactional
public Applicant save(Applicant applicant) {
    return this.em.merge(applicant);
}

申请人资源和申请人管理器类都是@RequestScoped。

失败服务的日志

2020-11-16 13:51:26,122 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) `hibernate.connection.provider_disables_autocommit` was enabled.  This setting should only be enabled when you are certain that the Connections given to Hibernate by the ConnectionProvider have auto-commit disabled.  Enabling this setting when the Connections do not have auto-commit disabled will lead to Hibernate executing SQL operations outside of any JDBC/SQL transaction.
2020-11-16 13:51:26,123 DEBUG [org.hib.SQL] (executor-thread-198) 
    select
        applicant0_.applicant_id as applican1_0_0_,
        applicant0_.email as email2_0_0_
    from
        applicants applicant0_
    where
        applicant0_.applicant_id=?
Hibernate: 
    select
        applicant0_.applicant_id as applican1_0_0_,
        applicant0_.email as email2_0_0_
    from
        applicants applicant0_
    where
        applicant0_.applicant_id=?
2020-11-16 13:51:26,156 DEBUG [org.hib.loa.pla.exe.pro.int.EntityReferenceInitializerImpl] (executor-thread-198) On call to EntityIdentifierReaderImpl#resolve, EntityKey was already known; should only happen on root returns with an optional identifier specified
2020-11-16 13:51:26,156 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Resolving attributes for [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Processing attribute `email` : value = original@email.com
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Attribute (`email`)  - enhanced for lazy-loading? - false
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Done materializing entity [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,159 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,159 DEBUG [org.hib.loa.ent.pla.AbstractLoadPlanBasedEntityLoader] (executor-thread-198) Done entity load : org.protechskillsinstitute.applicant.entity.Applicant#1
2020-11-16 13:51:26,159 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterTransaction
2020-11-16 13:51:26,160 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) `hibernate.connection.provider_disables_autocommit` was enabled.  This setting should only be enabled when you are certain that the Connections given to Hibernate by the ConnectionProvider have auto-commit disabled.  Enabling this setting when the Connections do not have auto-commit disabled will lead to Hibernate executing SQL operations outside of any JDBC/SQL transaction.
2020-11-16 13:51:26,160 DEBUG [org.hib.res.tra.bac.jta.int.JtaTransactionCoordinatorImpl] (executor-thread-198) Hibernate RegisteredSynchronization successfully registered with JTA platform
2020-11-16 13:51:26,161 DEBUG [org.hib.res.tra.bac.jta.int.JtaTransactionCoordinatorImpl] (executor-thread-198) JTA transaction was already joined (RegisteredSynchronization already registered)
2020-11-16 13:51:26,161 DEBUG [org.hib.eve.int.EntityCopyObserverFactoryInitiator] (executor-thread-198) Configured EntityCopyObserver strategy: disallow
2020-11-16 13:51:26,161 DEBUG [org.hib.loa.Loader] (executor-thread-198) Loading entity: [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,212 DEBUG [org.hib.SQL] (executor-thread-198) 
    select
        applicant0_.applicant_id as applican1_0_0_,
        applicant0_.email as email2_0_0_
    from
        applicants applicant0_
    where
        applicant0_.applicant_id=?
Hibernate:
    select
        applicant0_.applicant_id as applican1_0_0_,
        applicant0_.email as email2_0_0_
    from
        applicants applicant0_
    where
        applicant0_.applicant_id=?
2020-11-16 13:51:26,216 DEBUG [org.hib.loa.Loader] (executor-thread-198) Result set row: 0
2020-11-16 13:51:26,216 DEBUG [org.hib.loa.Loader] (executor-thread-198) Result row: EntityKey[org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Resolving attributes for [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Processing attribute `email` : value = original@email.com
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Attribute (`email`)  - enhanced for lazy-loading? - false
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Done materializing entity [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,218 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,218 DEBUG [org.hib.loa.Loader] (executor-thread-198) Done entity load
2020-11-16 13:51:26,219 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Processing flush-time cascades
2020-11-16 13:51:26,219 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Dirty checking collections
2020-11-16 13:51:26,219 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2020-11-16 13:51:26,220 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2020-11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=stephen.w.boyd@gmail.com}
2020-11-16 13:51:26,220 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,221 DEBUG [org.hib.eng.tra.int.TransactionImpl] (executor-thread-198) On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Processing flush-time cascades
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Dirty checking collections
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2020-11-16 13:51:26,222 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=edited@email.com}
2020-11-16 13:51:26,222 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,223 INFO  [org.hib.eng.int.StatisticalLoggingSessionEventListener] (executor-thread-198) Session Metrics {
    112700 nanoseconds spent acquiring 1 JDBC connections;
    9700 nanoseconds spent releasing 1 JDBC connections;
    147400 nanoseconds spent preparing 1 JDBC statements;
    340500 nanoseconds spent executing 1 JDBC statements;
    0 nanoseconds spent executing 0 JDBC batches;
    0 nanoseconds spent performing 0 L2C puts;
    0 nanoseconds spent performing 0 L2C hits;
    0 nanoseconds spent performing 0 L2C misses;
    3546700 nanoseconds spent executing 2 flushes (flushing a total of 2 entities and 0 collections);
    0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections)
}
2020-11-16 13:51:26,227 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterTransaction
2020-11-16 13:51:26,230 INFO  [org.hib.eng.int.StatisticalLoggingSessionEventListener] (executor-thread-198) Session Metrics {
    34900 nanoseconds spent acquiring 1 JDBC connections;
    18700 nanoseconds spent releasing 1 JDBC connections;
    77500 nanoseconds spent preparing 1 JDBC statements;
    430200 nanoseconds spent executing 1 JDBC statements;
    0 nanoseconds spent executing 0 JDBC batches;
    0 nanoseconds spent performing 0 L2C puts;
    0 nanoseconds spent performing 0 L2C hits;
    0 nanoseconds spent performing 0 L2C misses;
    0 nanoseconds spent executing 0 flushes (flushing a total of 0 entities and 0 collections);
    0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections)
}

代码和日志中的所有内容对于工作和非工作服务都是相同的,只有一个例外。 日志显示更新是工作服务所必需的,而不是失败的服务所必需的。

想法? 一如既往,感谢您的帮助!

在日志中钻孔

2020-11-16 13:51:26,156 DEBUG [org.hib.loa.pla.exe.pro.int.EntityReferenceInitializerImpl] (executor-thread-198) On call to EntityIdentifierReaderImpl#resolve, EntityKey was already known; should only happen on root returns with an optional identifier specified
2020-11-16 13:51:26,156 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Resolving attributes for [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Processing attribute `email` : value = original@email.com
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Attribute (`email`)  - enhanced for lazy-loading? - false

和支票

11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=edited@email.com}
2020-11-16 13:51:26,220 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,221 DEBUG [org.hib.eng.tra.int.TransactionImpl] (executor-thread-198) On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Processing flush-time cascades
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Dirty checking collections
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2020-11-16 13:51:26,222 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=edited@email.com}

你确定电子邮件真的改变了吗? 如果数据没有改变,Hibernate 显然不会执行更新查询。

根据已解决的依赖项,Red Hat 似乎正在使用:

  1. 休眠核心:5.4.21.Final-redhat-00001
  2. hibarenate-commons-annotations: 5.1.0.Final-redhat-00005
  3. 休眠-graalvm:5.4.21.Final-redhat-00001

根据下面的评论,我已经与 Red Hat 开了一张票。

案例 02805123

您是否尝试过在合并后刷新和提交? 您是否检查过冲洗模式是手动还是自动?

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM