node.js - Firestore 事务锁会阻止读取吗？ (服务端SDK)

Question

我有一个带有 @google-cloud/firestore 的 Node.js 应用程序，它有两个集合，A 和 B。

Collection A 文档有一个名为“name”的字段和一个名为“collectionBId”的字段。集合 B 文档只有一个名为“名称”的字段。集合 A 和 B 中的名称是唯一的。

// Collection A
{ id: 1, name: 'example1', nameB: 'example2' }

// Collection B
{ id: 1, name: 'example2' }

Node.js 中有一个端点可以:

const result = await firestore.runTransaction(async transaction => {
    const refA = firestore.collection('A').where('name', '==', reqParam1)
    const {docs: docsA} = await transaction.get(refA)
    const refB = firestore.collection('B').where('name', '==', docsA[0].data().name).where('name', '==', reqParam2)
    const {docs: docsB} = await transaction.get(refB)
    return docsB[0].data()
})

这明显快于(少了一次往返):

const {docs: docsA} = await firestore.collection('A').where('name', '==', reqParam1).get()
const {docs: docsB} = await firestore.collection('B').where('name', '==', docsA[0].data().name).where('name', '==', reqParam2).get()
const result = docsB[0].data()

事务在 Node.js 中以悲观锁运行，但不清楚多个用户是否可以同时使用此事务(例如 100 个用户)。

在文档中提到，当执行写入时，会有一个锁定来阻止并发写入是否也会阻止读取？另外，如果大量使用读取事务，是否会阻止写入？

这导致了以下两个问题:

1. Firestore 读取事务是否会阻止 Node.js 中的其他读取事务？
2. Firestore 读取事务是否会阻止 Node.js 中的写入事务？

Answer 1

(最终？)编辑 4:github issue被标记为已修复并且文档将被更新，所以现在我们知道交易是如何进行的 work :

You can use the transaction object passed to updateFunction to read and modify Firestore documents under lock. You have to perform all reads before before you perform any write.

Documents read during a transaction are locked pessimistically. Atransaction lock on a document blocks other transactions, batchedwrites, and other non-transactional writes from changing that document.A transaction releases its document locks at commit time or once it timesout or fails for any reason.

Transactions are committed once updateFunction resolves. If a transaction fails with contention, the transaction is retried up to five times. The updateFunction is invoked once for each attempt.

Transactions timeout after 60 seconds if no documents are read. Transactions that are not committed within than 270 seconds are also aborted.

编辑 3a:我从 Github repo 找到了更多关于交易的“官方”信息:

If you are reading a document using the runTransaction() API via a Server SDK the backend will prevent other clients from modifying the document until the transaction is committed. This lock can be held for up to 270 seconds. We refer to this as "pessimistic locking" in our documentation and all Firestore Server SDK expose these semantics.

There are some rare cases when the backend aborts currently runningtransactions (e.g. if there is too much contention), in which case allSDKs will retry, independent of how locks were obtained.

Also

If you have two transactions running that both try to read the samedocument, the first one will succeed and the second one will hanguntil the first one completes.

还提出了一个github issue要求改进有关交易的文档。

编辑 2: 对于服务器端 SDK，我找到了一个 response这可能会有所帮助，但是没有关于事务如何工作的官方文档，除了它运行悲观锁，理论上允许所有读取，除非它尝试写入，在这种情况下，它将在记录上放置一个独占锁，以防止其他用户操纵它

编辑:接下来的响应仅适用于运行乐观锁的客户端SDK，不适用于运行悲观锁的服务端SDK

1. 不，读取事务不会阻止另一个读取事务。
2. 不，读取事务不会阻止写入事务。

事实上，您必须意识到，如果在执行事务时读取的内容发生更改，则读取事务可能会运行多次，这样做是为了确保内容是最新的。

可以找到有关此行为的更多信息 here

if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction. This feature ensures that the transaction runs on up-to-date and consistent data.

这里

(When using transactions, note that) A function calling a transaction (transaction function) might run more than once if a concurrent edit affects a document that the transaction reads.