CODEWITHSUNDEEP
firebasegoogle-cloud-firestore
kcilc
kcilc

Reputation: 309

Server Side Locks in Cloud Firestore

I'm curious about the behavior of the locks that are performed when doing server side transactions on Cloud Firestore as mentioned in this video: https://www.youtube.com/watch?time_continue=750&v=dOVSr0OsAoU

My transaction will be reading multiple documents and placing locks on them. My question is do these locks restrict all access to the documents - including concurrent reads from client code that isn't part of a transaction? Or do they only restrict writes?

If they do restrict reads is there any way around this - it could lead to severe slowdown in the app I'm working on.

Also in the case that a transaction tries to lock documents that are already locked - what is the retry pattern - how often does it retry, and is there an exponential backoff?

Thanks!

Upvotes: 0

Views: 332

Answers (1)

Alex Mamo
Alex Mamo

Reputation: 1

My transaction will be reading multiple documents and placing locks on them.

A transaction operation is first reading the value of a property within a document in order to perform the write operation. So it requires round trip communications with server in order to ensure that the code inside the transaction completes successfully.

My question is do these locks restrict all access to the documents - including concurrent reads from client code that isn't part of a transaction?

The answer is no, concurrent users can read the content of the document even if you perform a write operation using a transaction.

Also in the case that a transaction tries to lock documents that are already locked - what is the retry pattern - how often does it retry, and is there an exponential backoff?

According to the official documentation regarding Firestore transactions, a transaction can fail only the following cases:

  • The transaction contains read operations after write operations. Read operations must always come before any write operations. The transaction read a document that was modified outside of the transaction. In this case, the transaction automatically runs again. The transaction is retried a finite number of times.

  • The transaction exceeded the maximum request size of 10 MiB.

  • Transaction size depends on the sizes of documents and index entries modified by the transaction. For a delete operation, this includes the size of the target document and the sizes of the index entries deleted in response to the operation.

A failed transaction returns an error and does not write anything to the database. You do not need to roll back the transaction; Cloud Firestore does this automatically.

Upvotes: 1

Related Questions