In the context of transactions, readers using READ_ONLY and writers using READ_WRITE may block each other when starting transactions, at least for cases where the underlying implementation uses locking for isolation. Since we allow multiple readers and they can start while other readers were already running, it's possible that readers end up starving writers in a concurrent setting. It seems it would be a good idea to add some minimum guarantees to the spec that ensures some amount of fairness to concurrent activities against a given database.
We could either include a loose recommendation or try to mandate a strict behavior. It seems the loose recommendation is more practical, the questions are a) is there a risk of incompatible behavior because of under-specification, and b) will we risk that some implementations will just ignore this aspect if it's specified too informally. The loose recommendation could just be a sentence in the transactions section: "UAs need to ensure a reasonable level of fairness across readers and writers to prevent starvation." If we wanted to be more specific, we could go with something like this (we'd probably spell it out as rules if we decide to put this strict version in the spec): "All readers can run concurrently, but once a writer tries to start a transaction we stop allowing new readers to start and queue up the writer and any subsequent reader/writer. Once the existing readers are drained the writer runs, and after that whatever is queued up next runs, which can be another writer or all the remaining readers (depending upon what came first, another writer or another reader; readers are released all simultaneously since they run concurrently)." Given that not all implementations will have to deal with this and that different implementations may want to have different strategies, it seems that just having the recommendation around starvation is the best option. Thanks -pablo
