如何避免JPA EclipseLink HistoryPolicy引发的唯一约束冲突

问题背景 #

使用EclipseLink的HistoryPolicy维护DATASET_PROGRESS表的历史记录时，历史表DATASET_PROGRESS_HISTORY的主键由源表ID+STATE_BEGIN时间戳组成。在并发请求或快速执行merge/persist的场景下，频繁触发主键唯一约束冲突。

优雅解决方案 #

• 提升时间戳精度
  冲突核心是同一ID的多次操作在极短时间内生成了相同的STATE_BEGIN时间戳（默认多为秒级精度）。可从两方面调整：

  1. 数据库层面修改STATE_BEGIN字段类型为高精度时间戳，比如MySQL的TIMESTAMP(6)（毫秒级）、Oracle的TIMESTAMP(9)（纳秒级）；
  2. 在HistoryPolicy中显式配置时间精度，确保EclipseLink写入的时间戳足够精细。

• 使用数据库生成的时间戳而非JVM时间
  JVM系统时间在高并发下可能存在重复或同步延迟，改为让数据库生成STATE_BEGIN的值：
  在DatasetProgressHistory的customize方法中添加：

  policy.setUseDatabaseTime(true);
  

  这样每次插入历史记录时，STATE_BEGIN会使用数据库的系统时间（如Oracle的SYSTIMESTAMP、MySQL的CURRENT_TIMESTAMP(6)），精度更高且由数据库保证事务内的唯一性。

• 调整历史表主键策略
  将历史表的主键改为独立的自增序列/标识列，同时把原有的ID + STATE_BEGIN设置为唯一索引。既避免了主键冲突，又能保证业务上的唯一性约束，适合对历史记录主键无特殊依赖的场景。

• 添加乐观锁控制
  在源表DatasetProgress中添加@Version注解的版本字段：

  @Version
  private long version;
  

  并发修改同一ID的数据时，EclipseLink会自动检查版本号，只有版本匹配的操作才会执行，从根源上减少同一ID的并发修改次数，进而降低历史表的冲突概率。

不推荐的方案 #

直接在merge/persist方法上加同步块虽能解决问题，但会严重降低并发性能，尤其是高流量场景下，不建议作为首选方案。

内容的提问来源于stack exchange，提问作者jansohn