首页 > 解决方案 > 使用合并休眠不一致和冲突的结果

问题描述

Quarkus 的版本 Red Hat Build


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

标签: javahibernatemergejax-rsquarkus

解决方案


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


推荐阅读