If underlying data within a Firestore transaction changes during a transaction (from outside the transaction), that transaction is retried to ensure current data. However, if that underlying data can only change from within transactions, are changes to that data effectively serialized? In other words, if a document can only be created and edited through a transaction, when one transaction is executing, are competing transactions (on that same document) made to wait? Is it first-in-first-out or can transactions on the same data interrupt each other?
1 Answers
Transactions are not serialized - this would not scale in the way that Firestore requires. From the perspective of web and mobile clients, transactions use "optimistic locking" to make changes. This style of locking doesn't actually force the document from being changed, it just indicates that the write might not complete the way it was expected because of another change. This is why transactions are retried (as described in the documentation) - if the document changes while the optimistic lock is held, the transaction is given another chance at making its change with the new contents of all documents involved in the transaction.
See also: Cloud Firestore document locking
Related