puta write transaction is used. Also if you
getan 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 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.
runInTransaction: Runs the given closure inside a transaction (comes in result-forwarding and/or throwing variants).
runInReadOnlyTransaction: Runs the given closure inside a read(-only) transaction. Unlike write transactions, multiple read transactions can run at the same time.
putcalls) in one transaction.
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
putwhen inside a read transaction: an exception will be thrown.
runInTransaction), one of the threads will be selected to go first, while the other threads have to wait. It works just like a lock.
DispatchQueue.syncor explicitly using
objc_sync_enter) 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”.