IssueTracker

Before V implementation could be done via reflection, see: https://source.corp.google.com/piper///depot/google3/java/com/google/android/gmscore/integ/modules/phenotype/src/com/google/android/gms/phenotype/common/DbWrapper.java;l=84

As I understand, Room serializes all transactions from all connections onto a single thread eagerly. If that's correct, how will this be implemented in Room so we can actually take advantage of multi-thread transactional readers?

From: https://developer.android.com/reference/androidx/room/RoomDatabase.Builder.html#setTransactionExecutor(java.util.concurrent.Executor)

... Room will not use more than one thread at a time from this executor since only one transaction at a time can be executed, other transactions will be queued on a first come, first serve order. ...

From: https://developer.android.com/reference/kotlin/androidx/room/package-summary.html#(androidx.room.RoomDatabase).withTransaction(kotlin.coroutines.SuspendFunction0)

Room will only perform at most one transaction at a time, additional transactions are queued and executed on a first come, first serve order.

It seems beginTransactionDeferred is a bit at odds with the current Transaction structure of Room?

Similar to how the framework had to make deferred transactions to use secondary connections (https://googleplex-android-review.git.corp.google.com/c/platform/frameworks/base/+/22775247) with the condition they be read-only, Room will also have to creates APIs to make it clear deferred transactions will not use the transaction executor that is serialized and instead use the regular multi-threaded query executor. I suspect we'll need to create a @ReadOnlyTransaction or similar API along side a coroutine equivalent withReadOnlyTransaction.