Transactions have to be done at the common ancestor of the data being modified, so it's best to use them for data that's nearby in the Firebase data tree. You /can/ do a transaction on a large chunk of data (e.g. the entire user list), but the client would need to sync the entire data and there'd be a greater chance of contention.
If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.
Comments
Transactions have to be done at the common ancestor of the data being modified, so it's best to use them for data that's nearby in the Firebase data tree. You /can/ do a transaction on a large chunk of data (e.g. the entire user list), but the client would need to sync the entire data and there'd be a greater chance of contention.
If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.