PAYATHON 2026

GridDB 并发写入时如何处理 10905 错误？

数据小陈

结论

错误文本显示，同一个 container 中有事务正在执行，因此其他事务进入等待状态，直到先执行的事务结束。示例关闭了 auto-commit，并在提交前等待 10 秒，延长了事务的打开时间，也增加了其他写入等待的可能。

仅凭错误文本和示例，无法确认 GridDB 在所有版本、连接和操作下的锁定规则，也无法判断事务最终失败是否由某个超时参数触发。需要结合实际使用的 GridDB 版本、服务端日志和客户端异常信息排查。

建议的处理方式

缩短事务范围

事务打开期间，避免执行 Thread.sleep、远程调用等不需要纳入数据库事务的耗时操作。尽量只在事务中执行必须原子提交的数据库操作；发生异常时，按约定关闭或回滚事务。示例可改为：

container.setAutoCommit(false);
try {
    for (int i = 0; i < 10; i++) {
        Row row = container.createRow();
        row.setString(0, "key" + i);
        row.setInteger(1, i);
        container.put(row);
    }

    container.commit();
} catch (GSException e) {
    // 如果事务仍处于活动状态，可按所用 GridDB Java API 版本的约定回滚。
    // 记录异常后再处理或抛出，避免吞掉写入失败。
    throw e;
} finally {
    container.close();
    store.close();
}

示例保留了原有的写入内容和 API 调用。回滚方式及资源关闭约定，请按项目使用的 GridDB Java API 版本确认。如果这些写入不需要作为一个整体原子提交，可以考虑启用 auto-commit，缩小每次写入的事务范围。这样，多行写入就不再由这段显式事务统一提交。

对可重试错误使用有界重试

如果确认当前场景中的错误属于暂时性等待失败，可以在应用层设置有限次数的重试，并逐步延长等待间隔。重试前要确认失败请求是否可能已经写入，并确保操作可以安全重放。例如，可以使用稳定的键，并处理重复写入的情况。还应记录重试次数、异常详情和最终结果，避免无限重试掩盖持续拥塞或配置问题。

根据数据语义评估拆分 container

只有当数据模型允许分区，且不同写入可以独立管理时，才考虑将数据放入不同的 container。拆分可能减少同一个 container 上的竞争，但也会影响数据组织和查询方式，不适合只为消除错误而机械拆分。

关于事务等待和超时配置

错误文本表明事务处于 standby 状态，正在等待先前的事务结束，但没有说明等待时长、最终失败机制或对应配置项。因此，无法据此确认是否存在可调整的事务等待超时参数，也不能推测参数名称或默认值。请查阅部署版本对应的 GridDB 配置文档，并结合服务端日志、客户端完整异常和事务持续时间定位失败原因。

备注：内容仅供参考。