Re: [IndexedDB] Avoiding reader/writer starvation
On Mon, Aug 16, 2010 at 3:06 AM, Jeremy Orlow wrote:
> On Fri, Aug 13, 2010 at 7:30 PM, Pablo Castro
> wrote:
>>
>> 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.
>
> I agree that we should have some (non-normative?) recommendation to avoid
> starvation in the spec and that anything more formal would be too
> constraining.
Sounds good to me. Here is the strategy that we're currently using in Firefox:
1. Transactions are always executed in the order they are "started".
Unless they can execute in parallel.
2. Transactions are considered to be started when the first request is
placed against them.
So in the following code:
trans1 = db.transaction(["foo"]);
trans1.objectStore("foo").get(...).onsuccess = ...;
trans2 = db.transaction(["foo"], READ_WRITE);
trans2.objectStore("foo").put(...).onsuccess = ...;
trans3 = db.transaction(["foo"]);
trans3.objectStore("foo").get(...).onsuccess = ...;
trans3 won't start until trans2 is committed.
/ Jonas
Re: [IndexedDB] Avoiding reader/writer starvation
On Fri, Aug 13, 2010 at 7:30 PM, Pablo Castro wrote: > 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. > I agree that we should have some (non-normative?) recommendation to avoid starvation in the spec and that anything more formal would be too constraining. J
[IndexedDB] Avoiding reader/writer starvation
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
