Sql 在使用复制的TypeForm中,我是否在EntityManager事务中时命中主实例?

Sql 在使用复制的TypeForm中,我是否在EntityManager事务中时命中主实例?,sql,postgresql,race-condition,typeorm,amazon-aurora,Sql,Postgresql,Race Condition,Typeorm,Amazon Aurora,我在AWS RDS上托管的Aurora PostgreSQL DB中遇到一些竞争条件问题。与正在发生的情况类似的一个例子是: 组表有一列usercenterlimits UserEntry表有一列userId和一列groupId 特定组的用户入口的不同用户的计数不得超过组的用户入口限制 在创建新UserEntry的事务中,我检查该组的当前UserEnters计数是否>=限制 如果不是,我继续创建一个新的UserEntry 在一些罕见的情况下,一个组出现的用户入口超过了其限制 我最初认为竞争条件是

我在AWS RDS上托管的Aurora PostgreSQL DB中遇到一些竞争条件问题。与正在发生的情况类似的一个例子是:

  • 组表有一列
    usercenterlimits
  • UserEntry表有一列
    userId
    和一列
    groupId
  • 特定组的用户入口的不同用户的
    计数
    不得超过组的
    用户入口限制
  • 在创建新UserEntry的事务中,我检查该组的当前UserEnters计数是否>=限制
  • 如果不是,我继续创建一个新的UserEntry
  • 在一些罕见的情况下,一个组出现的用户入口超过了其限制

  • 我最初认为竞争条件是因为读取副本不同步。但是,如果我正确理解typeorm的代码,事务将始终在master中执行。是这样吗?如果是这种情况,那么我假设竞争条件的实际解决方案是将事务的隔离级别更改为其他级别,例如
    SERIALIZABLE
    。我认为这是真的吗?

    如果您以直接调用
    entityManager.transaction()
    @transaction()
    装饰器中所述的方式使用它,并且如果您使用transaction提供的连接,则,事务使用master

    当我调试TypeForm源代码时,在启动事务时,
    entityManager.queryRunner
    undefined
    。因此,根据,将为每个事务创建queryRunner,但不提供复制模式,因此将使用默认(主)模式

    所以,逻辑中的问题比事务配置中的问题更可能出现