# 乐观锁并发提交冲突
乐观锁并发提交冲突的产生原因：多个修改作业（包括Insert、Update、Delete、MergeInto以及表服务操作）同时在LakeFormation上提交导致的并发提交冲突。例如：
![](https://support.huaweicloud.com/devg-fabric/figure/zh-cn_image_0000002482790789.png "点击放大")
上图中，Transaction1和Transaction2分别为两个DML事务，Transaction1基于元数据版本version1进行数据处理和提交，并将元数据版本更新至version2，而Transaction2在Transaction1提交前已经基于元数据版本version1开始了数据处理，在首次提交时，LakeFormation拒绝提交，因为此时元数据已经更新为version2，需要由Transaction2更新元数据后，再次提交。
在这种场景下，如果并发量非常大，或者某个事务做冲突检测的时间过久，则会陷入"提交冲突-\>更新元数据-\>检测冲突-\>再次提交"的死循环，导致业务冲突报错。
为解决上述问题，Iceberg引入四个参数。
表1参数说明 
| 参数名                           | 说明             | 高并发场景下建议值 | 表服务场景下建议值 |
|:---|:---|:---|:---|
| commit.retry.num-retries      | 最大重试次数         | 10        | 4         |
| commit.retry.min-wait-ms      | 提交失败后，最小提交等待时间 | 100       | 1000      |
| commit.retry.max-wait-ms      | 提交失败后，最大提交等待时间 | 10000     | 60000     |
| commit.retry.total-timeout-ms | 提交过程最长执行时间。    | 1800000   | 1800000   |