Re: [IndexedDB] Current editor's draft

On Jul 10, 2010, at 12:29 AM, Jonas Sicking wrote:

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

The point is that we are talking of leaving out dynamic scope in v1, while, in the same vein, talking of making READ_ONLY the default _because_ it produces "good" performance. That is, IMHO, contradictory.

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

This seems to be conveniently justified. A strict interpretation of the objective would not require the programmer to specify READ_WRITE even though that involves less mental (cognitive) and physical (typing) effort. 

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

It should have worked right the first time. Why wait for a programmer to find out why their 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.

There are many ways to get performance improvement, including dynamic transactions, which you seem not to be favorable towards. I don't see why READ_ONLY should be given special treatment.

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

Various hints are used in SQL syntax, e.g., [1], to manage locks, a certain kind of B-tree behavior, or a level of isolation. These are all aimed at improving performance, but they are set as default behavior. My point is that expecting good performance from a single variable in database systems out of possibly hundreds is not all that helpful. It is also a slippery slope because it confuses performance with options. The database's job is to be fast at what it does, not play performance tricks using default values.

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

I don't know that we can make the right performance decisions for people. What we can do is make things perform well and provide tools to improve performance.

[1] http://msdn.microsoft.com/en-us/library/ms187373.aspx

Received on Friday, 9 July 2010 19:50:49 UTC