Re: [IndexedDB] Current editor's draft

On Fri, Jul 9, 2010 at 11:05 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:
> 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:

I'm not sure I understand the question. We would use separate
functions for creating dynamic and static transactions so there is no
such thing as "default".

> 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.

As far as I can see this does not significantly complicate
development. In fact, in the process of writing test cases I have
several times forgotten to specify lock type. For the cases when I
needed a READ_WRITE lock, the code didn't work. As always when things
don't work my first reaction was to go look at the error console which
showed a uncaught exception which immediately showed what the problem
was.

So I argue that this does not meaningfully increase the effort
required to use IndexedDB.

Using the other lock type as default does however meaningfully
increase the effort required to get optimal performance, which I think
we should take into account.

> 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.

Certainly. I was just enumerating all the reasons I could think of why
either default would be preferable. I similarly haven't seen any
evidence why write transactions are more common.

Though I will note that both the example programs that you have
written, as well as ones we have written for a few demos, use more
read transactions than write transactions. (I can attach those if
anyone is interested, though note that they are very specific to the
API we currently have implemented).

> 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.

I don't understand what you mean here. Could you elaborate?

> 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.

I don't understand why the lack of dynamic transactions would affect
what default lock type we should use for static transactions.

In fact, if you are concerned that lack of dynamic transactions will
cause people to lock the entire database and thus reduce concurrency
(is that your concern?), then it seems like using READ_ONLY as default
addresses that concern better than using READ_WRITE. Or am I
misunderstanding something?

/ Jonas

Received on Friday, 9 July 2010 19:00:38 UTC