I know Firestore uses locks for Transactions in the SERVER (cloud-functions), as explained by this video: https://www.youtube.com/watch?v=dOVSr0OsAoU
The video explains in detail how Transactions work in the CLIENT (and it's not using locks there), but doesn't do such a good job for SERVER Transactions.
Which of these is true (about SERVER Transactions)?:
1) A document is locked by get
s in a server Transaction, so that other server Transactions cannot get
it before the first Transaction is finished.
2) A document is locked by get
s in a server Transaction, but only for writes, so that other server Transactions can get it but not modify it before the first transaction is finished.
3) A document is NOT locked by get
s in a server Transaction, only writes.
EDIT: I need authoritative sources (documentation or some reference in video or blogs from someone in the Firebase Team).
Server side transactions work in general like client libraries but instead of that concurrency model tehnique mentioned in that video, work in the traditional way of locking data. So even if you use a transaction on a single document or on a query, those documents will be locked till the transaction is complete.
To answer your question, because a transaction that is coming from a cloud function is taking place internally (can take a few milliseconds), the documents are locked for that amount of time. This means that those documents can not be taken or changed by any other transactions.
1) A document is locked by gets in a server Transaction, so that other server Transactions cannot get it before the first Transaction is finished.
Correct.
2) A document is locked by gets in a server Transaction, but only for writes, so that other server Transactions can get it but not modify it before the first transaction is finished.
It makes no sense for another transaction to get a locked document. Why to try to get such a document since it cannot be changed? Moreover, a locked document might have by the time the transaction completes, different values. Between the start of the transaction and when it completes, some properties within the document are changed.
3) A document is NOT locked by gets in a server Transaction, only writes.
The document is locked once the cloud function run the transaction and the lock is released when the transaction is completed.
Edit:
It does make sense for another transaction to get a locked document. It cannot be changed, but if it can be read
I was referring strictly in terms of writing. All documents can be read, no matter if the document is locked or not.
if you just want to read the value
If you just want to read the value, there is nothing to worry about. There are no locks on documents when it comes to reads.
Maybe you need to read some value to make a decision regarding changing another document, or even just showing some info to the user.
It will work perfectly fine.
Also, depending on the transaction, you don't care if the document changes within the next second. For example, if the user wants to know the money amount in his bank account, you can show a value from one second before, no problem.
Yes, that's correct. There are no restrictions when it comes to read operations and regarding your example, yes, it's fine. This is also working in one of my projects.
Could you please point me to their sources?
There are many resources out there that explain how traditional way of locking data work. The server side transactions are working this way, as Todd Kerpelman confirmed in the liked video. The purpose of this locking is to serve and protect shared resources (documents).
I really need to be absolutely sure of that, so I need the sources, or else someone from the Firebase team confirming them.
Let's also hope that someone from the Firebase team will take the time and look at this but I'm not sure I understand what are your concerns? Do you think that while a transaction is taking place, you won't be ablte to read the documents? Or?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With