To make the server-side API non-blocking and perform well, all method calls are asynchronous. This means that to act on any results of a BigDB operation, that code has to be put in callbacks. For the CreateObject and Save methods the callbacks are optional, so if you need to take an action after the object has been saved you can specify a callback, otherwise you can just leave it out and "fire and forget" about the update.
However, all load methods require a callback, and any code using the loaded object has to be placed in there. There is also an optional error callback that you can specify if you anticipate errors and need to handle those, like in this example:
As long as you only load one object at a time, it's fairly easy to deal with asynchronous methods, but if you need to load multiple objects and take an action when all objects are loaded, it gets a bit trickier. Fortunately, you can use this simple pattern:
The idea is that the loadedUsers method will be called twice, but the first time it is called, only one of the users will have been loaded so it will do nothing, but the second time it is called, both will be loaded, and your code can execute. This way, it also doesn't matter which user is actually loaded first.
BigDB also features optimistic locking. When you want to avoid overwriting changes to shared data that are loaded and manipulated in several places, you have to solve the synchronization issue somehow. One way is to do it via traditional locking where the shared data can only be manipulated in one place at a time, and everyone else have to wait their turn.
With optimistic locking anyone can read and modify the shared data, but if you try to save your updates after someone else has already saved theirs, you will get an error and can then reload the data and try again. If for example you have some sort of shared counter in a game, you could safely increment it like this: