java - Hibernate线程安全幂等upsert无约束异常处理？

Question

我有一些执行 UPSERT 的代码，也称为 Merge 。我想清理这段代码，具体来说，我想摆脱异常处理，并减少这样一个简单操作的代码的整体冗长和复杂性。要求是插入每个项目，除非它已经存在:

public void batchInsert(IncomingItem[] items) {
    try(Session session = sessionFactory.openSession()) {
        batchInsert(session, items);
    }
    catch(PersistenceException e) {
        if(e.getCause() instanceof ConstraintViolationException) {
            logger.warn("attempting to recover from constraint violation");
            DateTimeFormatter dbFormat = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS");
            items = Arrays.stream(items).filter(item -> {
                int n = db.queryForObject("select count(*) from rets where source = ? and systemid = ? and updtdate = ?::timestamp",
                        Integer.class,
                        item.getSource().name(), item.getSystemID(), 
                        dbFormat.format(item.getUpdtDateObj()));
                if(n != 0) {
                    logger.warn("REMOVED DUPLICATE: " +
                            item.getSource() + " " + item.getSystemID() + " " + item.getUpdtDate());
                    return false;
                }
                else {
                    return true; // keep
                }
            }).toArray(IncomingItem[]::new);
            try(Session session = sessionFactory.openSession()) {
                batchInsert(session, items);
            }
        }
    }
}

对 SO 的初步搜索并不令人满意:

• Hibernate Idempotent Update - 概念上相似但更简单的场景，不考虑多线程或多处理。
• Can Hibernate work with MySQL's "ON DUPLICATE KEY UPDATE" syntax?更好的是，通过使用 @SQLInsert 注释将原子性推送到数据库来消除竞争条件；不幸的是，这个解决方案太容易出错，无法在更广泛的表上使用，并且在不断发展的应用程序中需要大量维护。
• How to mimic upsert behavior using Hibernate?与上面的问题非常相似，答案也相似
• Hibernate + "ON DUPLICATE KEY" logic与上面相同，答案提到 merge() 这在单线程时没问题
• Bulk insert or update with Hibernate?类似的问题，但使用存储过程选择的答案是不合时宜的
• Best way to prevent unique constraint violations with JPA又是非常天真的、面向单线程的问题和答案

在问题How to do ON DUPLICATE KEY UPDATE in Spring Data JPA?中被标记为重复项，我注意到这个有趣的评论:

这是一个死胡同，因为我真的不明白这个评论，尽管它听起来像是一个聪明的解决方案，并且提到了“实际相同的 SQL 语句”。

另一个有前途的方法是:Hibernate and Spring modify query Before Submitting to DB

冲突时不执行任何操作/重复 key 更新

两个主要的开源数据库都支持将幂等性下推到数据库的机制。下面的示例使用 PostgreSQL 语法，但可以轻松适应 MySQL。

遵循Hibernate and Spring modify query Before Submitting to DB中的想法, Hooking into Hibernate's query generation ，和How I can configure StatementInspector in Hibernate? ，我实现了:

import org.hibernate.resource.jdbc.spi.StatementInspector;

@SuppressWarnings("serial")
public class IdempotentInspector implements StatementInspector {

    @Override
    public String inspect(String sql) {
        if(sql.startsWith("insert into rets")) {
            sql += " ON CONFLICT DO NOTHING";
        }
        return sql;
    }

}

有属性(property)

        <prop key="hibernate.session_factory.statement_inspector">com.myapp.IdempotentInspector</prop>

不幸的是，当遇到重复项时，这会导致以下错误:

Caused by: org.springframework.orm.hibernate5.HibernateOptimisticLockingFailureException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; nested exception is org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1

如果您考虑一下幕后发生的事情，这是有道理的:ON CONFLICT DO NOTHING 会导致插入零行，但预计会插入一个。

有没有一种解决方案可以实现线程安全、无异常的并发幂等插入，并且不需要手动定义 Hibernate 执行的整个 SQL 插入语句？

就其值(value)而言，我认为将重复检查推送到数据库的方法是找到正确解决方案的途径。

澄清batchInsert 方法使用的 IncomingItem 对象源自记录不可变的系统。在这种特殊情况下，ON CONFLICT DO NOTHING 的行为与 UPSERT 相同，尽管可能会丢失第 N 个更新。

Answer 1

简短回答 - Hibernate 不支持开箱即用(正如 this blog post 中 Hibernate 专家所证实的那样)。也许您可以使用您已经描述的机制在某些情况下使其在某种程度上发挥作用，但直接使用 native 查询对我来说是实现此目的最直接的方法。

更长的答案是，考虑到我认为 Hibernate 的所有方面，很难支持它，例如:

• 如何处理找到重复项的实例，因为它们应该在持久化后受到管理？将它们合并到持久化上下文中？
• 如何处理已经持久化的关联，对它们应用哪些级联操作(持久/合并/something_new；或者此时做出决定是否为时已晚)？
• 数据库是否从 upsert 操作中返回足够的信息来涵盖所有用例(跳过的行；在批量插入模式下为不跳过生成的键等)。
• @Audit 编辑的实体怎么样？它们是创建还是更新，如果更新则发生了什么变化？
• 或者版本控制和乐观锁定(根据定义，在这种情况下您实际上希望出现异常)？

即使 Hibernate 以某种方式支持它，如果有太多需要注意和考虑的警告，我也不确定我是否会使用该功能。

所以，我遵循的经验法则是:

• 对于简单场景(大多数情况下):坚持+重试。发生特定错误时的重试(通过异常类型或类似)可以使用类似 AOP 的方法(注释、自定义拦截器等)进行全局配置，具体取决于您在项目中使用的框架，无论如何，这都是一个很好的实践，尤其是在分布式环境中.
• 对于复杂场景和性能密集型操作(尤其是批处理、非常复杂的查询等): native 查询可最大限度地利用特定数据库功能。