GridDB错误10905(TXN_WAIT_FOR_TRANSACTION_END)并发写入处理问询

错误信息 #

10905 TXN_WAIT_FOR_TRANSACTION_END ERROR

Processing of transaction event continued to be in standby status.

Other transactions may be under execution.

Multiple clients are executing transactions in the same container at the same time.

Transactions on standby will be executed when the earlier transactions end.

复现代码 #

import java.util.Properties;
import com.toshiba.mwcloud.gs.*;

public class GridDBTransactionTest {

    public static void main(String[] args) throws Exception {

        Properties props = new Properties();
        props.setProperty("notificationAddress", "239.0.0.1");
        props.setProperty("notificationPort", "31999");
        props.setProperty("clusterName", "myCluster");
        props.setProperty("database", "public");
        props.setProperty("user", "admin");
        props.setProperty("password", "admin");

        GridStore store = GridStoreFactory.getInstance().getGridStore(props);

        Container<String, Row> container = store.getContainer("SampleContainer");

        // Explicit transaction start
        container.setAutoCommit(false);

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

            container.put(row);
        }

        // Simulate long processing before commit
        Thread.sleep(10000);

        container.commit();
        container.close();
        store.close();
    }
}

问题解答 #

1. 10905错误的具体成因

GridDB对同一容器的显式事务（非自动提交模式）采用排他锁机制：同一时间同一容器仅允许一个活跃的显式事务，其他并发事务会进入等待队列。当等待队列中的事务等待时间超过设定的超时阈值时，就会触发10905错误，提示事务长期处于待机状态无法执行，最终失败。示例代码中事务持有时间长达10秒，极易导致后续并发事务等待超时。

2. 是否由容器级锁导致？

是的。GridDB的显式事务在容器层面是排他锁，当一个连接开启显式事务并持有容器锁时，其他连接的事务必须等待锁释放。如果锁持有时间过长，后续事务等待超时就会触发该错误。

3. 并发写入的推荐处理方式

• 使用自动提交模式：默认的自动提交（setAutoCommit(true)）下，每个写入/更新操作都是独立的短事务，GridDB会自动快速释放锁，大幅减少事务等待时间，适合高并发单条写入场景。
• 缩小事务范围：若必须使用显式事务，需严格控制事务持有时间，避免在事务中执行非数据库操作（如示例中的Thread.sleep），完成数据操作后立即执行commit或rollback，尽快释放容器锁。
• 拆分容器：将数据按业务维度（如用户ID哈希、时间分片、业务模块）拆分到多个容器，分散并发压力，避免单个容器成为锁竞争瓶颈。
• 实现重试逻辑：针对10905错误，实现指数退避的重试机制，事务失败后等待一段递增的时间再重新执行，避免短时间内重复请求加剧锁竞争。
• 批量操作优化：在自动提交模式下使用putAll等批量写入接口，减少事务次数，提升整体写入吞吐量。

4. 控制事务超时或等待行为的配置参数

• 客户端参数：transactionTimeout：在连接Properties中设置，单位毫秒，控制单个事务的最大执行时间（包括等待时间），默认值为60000ms（60秒）。示例配置：props.setProperty("transactionTimeout", "30000")。
• 集群节点参数：txnWaitTimeout：在集群配置文件gs_cluster.json中设置，单位毫秒，控制事务等待容器锁的最长时间，默认值为60000ms。调整该参数可改变事务在等待队列中的容忍时长。
• 时序容器并发参数：concurrencyMode：针对时间序列容器，可设置为CONCURRENCY_MODE_HIGH，开启高并发写入模式，提升时序数据的并发处理能力。

GridDB并发事务最佳实践 #

• 优先采用自动提交模式处理高并发单条写入场景，最小化锁持有时间。
• 显式事务仅用于必须原子性执行的多操作场景，且严格缩短事务生命周期，避免包含非DB操作。
• 按业务规则拆分容器，分散锁竞争压力，避免单个容器成为并发瓶颈。
• 根据业务场景合理配置超时参数：超时过短会导致频繁重试，过长会占用资源，需平衡调整。
• 针对10905错误实现重试逻辑，配合指数退避策略，降低重试对集群的冲击。
• 批量处理写入请求，减少事务次数，提升整体吞吐量。
• 通过GridDB监控工具（如gs_stat）跟踪事务等待时间和锁竞争情况，及时优化配置或业务逻辑。

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