0

I am only interested in atomic transactions and strong consistency. Does firebase realtime db supports both?

  • I don't see any transaction locks in firebase db anywhere. And, it is required to take lock on item to support atomicity. That's my first thought that probably firebase db is not an atomic db.
  • I also don't know the back-end atchitecture of firebase db. I am not sure if it always read from master node or slave nodes too. So can't not ensure whether it is strongly consistent or eventual consistent.
sn.anurag
  • 617
  • 7
  • 14

1 Answers1

2

Realtime Database supports transactions. Clients must all agree how to cooperate with respect to these transactions. The database doesn't support any sort of operation that locks the entire database in order to serialize access from all client. You need to understand how RTDB transactions work in order to make effective use of them. Not all writes will require a transaction, and you need to figure out for yourself when and how best to use them in your particular application.

Since Realtime Database is a cloud-hosted database, you don't need to know (or care) about any sort of master/slave configuration. In fact, you can just assume that it works as the documentation suggests. The documentation suggests that it's eventually consistent if the client is offline at the time of a write operation (which will be cached locally and synchronized when it becomes online). It's immediately consistent if the client is already online, and the client is willing to "wait around" for the latest update as it listens to changing data in the database, whenever it becomes available to the client. (There are actually no "replicas" to speak of with Realtime Database, except the local caches that each client may maintain for themselves for data previously read.)

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • Thanks for point out this documentation. I somehow, had missed it. Actually, I think, they have not public there architecture. It had helped to know the level of operations it supports. Apparently, it seems they must be having locks if they are supporting transactions (element level locks not db level). Update is a 2 step operation. It reads the entity first and write the new entity. And, if Update operation is supported in transaction then they must be having locks working behind the scene at server level or fs level. But, sure, we don't need to worry about it. – sn.anurag May 13 '19 at 04:42
  • It's a optimistic lock, not a pessimistic (hard) lock. https://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking – Doug Stevenson May 13 '19 at 04:43
  • And, what you said about consistency, that it is not consistent when offline and immediate consistent if online. That is actually availability. It is not consistency. Can you please point me where you saw in documentation that it is eventually consistent? I only mentioned master/slave working behind the scene to have better understanding of consistency. Thanks again :) – sn.anurag May 13 '19 at 04:49
  • It's eventually consistent because the write commits while offline, and you have no guarantee when the write will be synchronized and available to others, or how it will work in tandem with writes from other clients (last write wins in any event, no matter how long of a delay). The fact that the database isn't "available" isn't the issue. The SDK considers the database to be always available, but might service reads or writes differently depending on connectivity. – Doug Stevenson May 13 '19 at 04:57