# 如何处理乐观锁并发提交元数据冲突
在并发写入Iceberg表时，通常会遇到两类冲突：并发提交数据冲突、乐观锁并发提交元数据冲突。
本文介绍乐观锁并发提交元数据冲突。
乐观锁并发提交元数据冲突的产生原因：多个修改作业（包括Insert、Update、Delete、MergeInto以及表服务操作）同时在LakeFormation上提交导致的并发提交冲突。例如：
![](https://support.huaweicloud.com/devg-aidatalake/zh-cn_image_0000002671427110.png "点击放大")
上图中，Transaction1和Transaction2分别为两个DML事务，Transaction1基于元数据版本version1进行数据处理和提交，并将元数据版本更新至version2，而Transaction2在Transaction1提交前已经基于元数据版本version1开始了数据处理，在首次提交时，LakeFormation拒绝提交，因为此时元数据已经更新为version2，需要由Transaction2更新元数据后，再次提交。
在这种场景下，如果并发量非常大，或者某个事务做冲突检测的时间过久，则会陷入"提交冲突-\>更新元数据-\>检测冲突-\>再次提交"的死循环，导致业务冲突报错。
为解决上述问题，Iceberg引入四个参数，具体参数说明请参见[表1]。
 表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   |