Difference between firestore transactions and FieldValue.increment when updatiing a counter on firestore

user_5992689 0
Viewed 909

I know this question has been asked before and the firebase official documentation also suggests that both these have exactly the same effect.

However I have confusion in perceiving both as same because of a few things:

  1. transactions are retried on abortion automatically while there is no mention in the documentation that FieldValue.increment() does the same.
  2. as mentioned in the documentation The maximum write rate of a firestore document is one write per second, so one can not update a single counter more than once a second using FieldValue.increment(). But what the documentation does not mention is that what happens in this case? For Example if FieldValue.increment() is called twice in one second, does the second call to FieldValue.increment() fails completely, or it is blocked untill that one second is passed and then gets executed after that or some other thing happens.
  3. If two identical transactions for updating the same counter are run by two different clients at the exact same time, will one of the transactions get aborted and retried?

Considering the above points, I feel that transactions are more safe for updating counters particularly in a case where for example multiple clients can update a single counter, so if the above assumptions are true FieldValue.increment() will fail whenever two or more clients try to update the counter within a span of one second. But doing the same with transactions there will be the advantage of automatic retrying upon abortion due to concurrency.

So what I want to know is that are my assumptions correct? If not then in what way exactly the above 3 things are done? Also considering the example of multiple users updating a single counter, is there an advantage of using transactions over FieldValue.increment().

google-cloud-firestore firebase concurrency transactions
1 Answers

  1. Unlike transactions, there is no round trip required between the client and server for a conflicting increment operation. That's because there is no need for the client to recompute the new value. The server is well aware that it is only going to be an increment of an existing field of a single document, and it can retry internally on its own.

  2. In the event that a limit is exceeded, the write operation will fail, just like any other write operation that exceeds a limit. There is nothing special about increments in this respect. Bear in mind that two rapid changes to a document will not necessarily fail outright. The limit of 1 change per second is a sustained limit. The system can handle a few rapid changes over a short period of time, but that can't be sustained indefinitely. Again, this applies to all writes, not just increments.

  3. No, each transaction will drive independently to creation. It doesn't matter if there are any "identical" transactions (in whatever way you define that).

There is no advantage to using transactions over increments if all you're doing is updating a single document. However, you are required to use a transaction if you have updates across multiple documents that must be atomic.

user_8071260
Related