put
a write transaction is used. Also if you get
an object or query for objects, a read transaction is used. All of this is done under the hood and transparent to you. It may be fine to completely ignore transactions altogether in your app without running into any problems. With more complex apps however, it’s usually worth learning transaction basics to make your app more consistent and efficient.put
calls) in one transaction.get
, count
, and queries run inside an implicit read transaction if they are not called when already inside an explicit transaction (read or write). Note that it is illegal to put
when inside a read transaction: an exception will be thrown.put
or runInTx
), one of the threads will be selected to go first, while the other threads have to wait. It works just like a lock or synchronized
in Java.synchronized
or java.util.concurrent.locks
) when inside a write transaction when possible. Because write transactions run exclusively, they effectively acquire a write lock internally. As with all locks, you need to pay close attention when multiple locks are involved. Always obtain locks in the same order to avoid deadlocks. If you acquire a lock “X” inside a transaction, you must ensure that your code does not start another write transaction while having the lock “X”.