Re: [IndexedDB] Current editor's draft

We would not make dynamic transactions be the default since they would produce more concurrency than static scoped transactions, correct?

On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:

>>> Unless we're planning on making all
>>> transactions dynamic (I hope not), locks have to be grabbed when the
>>> transaction is created, right? If a transaction is holding a READ_ONLY
>>> lock for a given objectStore, then attempting to open that objectStore
>>> as READ_WRITE should obviously fail. Consecutively, if a transaction
>>> is holding a READ_WRITE lock for a given objectStore, then opening
>>> that objectStore as READ_ONLY doesn't seem to have any benefit over
>>> opening it as READ_WRITE. In short, I can't see any situation when
>>> you'd want to open an objectStore in a different mode than what was
>>> used when the transaction was created.
>>> 
>>> Finally, I would stronly prefer to have READ_ONLY be the default
>>> transaction type if none is specified by the author. It is better to
>>> default to what results in higher performance, and have people notice
>>> when they need to switch to the slower mode. This is because people
>>> will very quickly notice if they use READ_ONLY when they need to use
>>> READ_WRITE, since the code will never work. However if people use
>>> READ_WRITE when all they need is READ_ONLY, then the only effect is
>>> likely to be an application that runs somewhat slower, when they will
>>> unlikely detect.
>> 
>> This approach is also likely to cause exceptions upon put, remove, and add.
>> I would prefer to not cause exceptions as the default behavior.
> 
> If we use READ_WRITE as default behavior then it's extremely likely
> that people will use the wrong lock type and not realize. The downside
> will be that sites will run less concurrently, and thus slower, than
> they could.

All along our primary objective with IndexedDB is to assist programmers who are not well versed with database programming to be able to write simple programs without errors. By that token, reducing the effort required for their use of IndexedDB seems to be the primary criteria and not great concurrency. 

> Another downside is that authors should specify lock-type
> more often, for optimal performance, if we think that READ_ONLY is
> more common.

You haven't provided any evidence about this yet. 

> 
> If we are using READ_ONLY as default behavior, then it's extremely
> likely that people will use the wrong lock type, notice that their
> code isn't working, and fix it. The downside is that people will have
> to fix their bugs. Another downside is that authors will have to
> specify lock-type more often if we think that READ_WRITE is more
> common.

It is quite common in various languages to specify as a performance or safety hint when someone desires a shared lock and use a read-write version by default. 

> 
> To me the downsides of using READ_WRITE as a default are much worse
> than the downsides of using READ_ONLY.

For all we know, programmers would lock the entire database when they create a transaction. If dynamic transactions appear to be a non-v1 feature, then READ_ONLY being default appears out of place.