Room database and transactions

I am a novice when it comes to databases and I was looking into transactions with android room database. When using RoomDatabase.withTransaction the documentation says

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

From what I understand this means a transaction is doing essentially the same thing as locking every block of code I want to run a transaction on inside a mutex (I think this is done because of Isolation). However I also noticed that this restriction only applies to each database. For example if I make MyDatabaseOne and MyDatabaseTwo the transactions can run asynchronously. I also noticed that transactions from MyDatabaseOne and MyDatabaseTwo seem to be able to be nested.

So my questions are, what is the downside of just using a separate database for each table? Does it restrict the ability to use Joins? Does doing this increase the capability to run queries concurrently (for example long running transactions)?

Edit:

I figured I would put this here in case anyone stumbles on this question. An important consideration for room from the documentation is below.

Note: If your app runs in a single process, you should follow the singleton design pattern when instantiating an AppDatabase object. Each RoomDatabase instance is fairly expensive, and you rarely need access to multiple instances within a single process.

Solution

So my questions are, what is the downside of just using a separate database for each table? Does it restrict the ability to use Joins?

Yes unless you attach one to the other, they are otherwise separate files handled separately and joins will not work (although I believe that you could perhaps mimic joins to some extent by using IN).

If there is an attached database then schema names (the name given to the attachment or main) may have to be utilised and thus joins may be more a little more complicated.

If attached then I believe that transactions basically work in the same way to include the attached database, so the concurrency is the same. i.e. the link includes :-

Transactions involving multiple attached databases are atomic, assuming that the main database is not ":memory:" and the journal_mode is not WAL. If the main database is ":memory:" or if the journal_mode is WAL, then transactions continue to be atomic within each individual database file. But if the host computer crashes in the middle of a COMMIT where two or more database files are updated, some of those files might get the changes where others might not.