Re: [WebStorage] Solution proposed (was: Concerns on spec section 'Processing Model')

If you want to provide an application programmer with a limited degree  
of freedom from a certain class of errors, then there is a different  
solution. It is called isolation level [1]. When opening a  
transaction, just provide the required isolation level. Heck, if you'd  
like, make "SERIALIZABLE" the default value.

But don't disallow other possibilities or create the illusion of  
silver bullets.

On Jul 24, 2009, at 2:53 PM, Ian Hickson wrote:

> On Fri, 24 Jul 2009, Laxmi Narsimha Rao Oruganti wrote:
>>
>> Let me probe this further to get clarity.
>>
>>> As I understand it, with what is specced now, if you try to get a
>>> write transaction lock, it will only fail if it times out, which  
>>> would
>>> probably be a symptom of a more serious bug anyway. There's never
>>> going to be a forced rollback; once you have got a transaction lock,
>>> you are not going to ever have it fail on you unexpectedly.
>>
>> My understanding of your requirement is "Database should allow only  
>> one
>> active writer transaction".  How the database systems achieve this  
>> need
>> not be explained.
>
> Sure, so long as the implementation is black-box indistinguishable  
> from
> what the spec says, it can do whatever it wants.
>
>
>> Note that, this need not be achieved only by acquiring an exclusive  
>> lock
>> on the database file.  Think about a database implementation which is
>> not a single file based (Log + Checkpoint design model) where there  
>> is
>> one data file and a couple of log files.  Spec-ing that they have to
>> hold exclusive lock on database file is ambiguous between data file  
>> and
>> log file.  If you take BDB JE as an example, they don't even have  
>> data
>> file.  Their model is a sequence of log files.
>
> The exclusive lock model described in the spec is just a model, it  
> isn't
> intended to be actually require an exclusive lock. If an  
> implementation
> can get the same result using some other mechanism, that's fine.

The spec says:
[[
If the mode is read/write, the transaction must have an exclusive  
write lock over the entire database
]]

Therefore, correct me if I am wrong, but the spec prohibits the  
following:

An implementation of the Database object allows more than one  
transaction to write in a database while another transaction has a  
write lock on the same database, it is a failure.

If so, then I want to formally object to that spec text because it is  
overly restrictive on implementers as well as on application  
programmers.

>
> [snip]
>
>> 3. A read-only transaction includes inside it a read-write  
>> transaction.
>
> This isn't possible with the current asynchronous API as far as I can
> tell. With the synchronous API, it would hang trying to open the
> read-write transaction for however long it takes the UA to realise  
> that
> the script that is trying to get the read-write transaction is the  
> same
> one as the one that has an open read-only transaction, and then it  
> would
> fail with error code 7.

Then again the spec is too restrictive because application programmers  
need the ability to upgrade their lock from read-only to read-write  
and an application should never deadlock itself. We would have failed  
the same dumb programmer if we didn't allow this.

Therefore, I formally object to the spec disallowing an application to  
upgrade its database lock.

>
>
>> Experience has shown that there is no easy way out when dealing with
>> transactions, and locking at the whole database level is no  
>> solution to
>> failures.
>
> It's not supposed to be a solution to failures, it's supposed to be,  
> and
> is, as far as I can tell, a way to make unpredictable, transient,
> intermittent, and hard-to-debug concurrency errors into guaranteed,
> easy-to-debug errors.

How is a timeout an easy-to-debug error? What is the meaning of a  
guaranteed error? How is a guaranteed error better than its opposite?  
Do you have any facts to back this up? If not, I would like to avoid  
using that judgement.

>>> I think this is an important invariant, because otherwise script
>>> writers _will_ shoot themselves in the foot.
>>
>> Even if the transaction lock doesn't fail, how would one deal with  
>> other
>> transaction failures?
>
> I don't understand the relevance. If there's a hardware error,  
> retrying
> isn't going to help. If there's a concurrency error, the only solution
> will be to design complex locking semantics outside the API, which  
> would
> be a terrible burden to place on Web authors.

As I explained in my simple example of updating a spreadsheet cell,  
users cannot avoid complex semantics when dealing with concurrency and  
sharing in the face of consistency needs. It is an end-to-end  
reliability requirement (in the same sense as that used by Saltzer,  
Reed and Clark), and unavoidable for all but the unreliable systems.

>
>
>>> These aren't professional database developers; Web authors span the
>>> gamut of developer experience from the novice who is writing code  
>>> more
>>> by luck than by knowledge all the way to the UI designer who wound  
>>> up
>>> stuck with the task for writing the UI logic but has no professional
>>> background in programing, let alone concurrency in databases.
>>
>> This is a strong reason to avoid SQL in the front-end.
>
> I understand that SQL is not a popular solution for everyone, yes.
> Hopefully other solutions will be proposed (so far none have been  
> proposed
> that are serious contenders.)

I beg to differ other solutions have been proposed and, one (B-tree  
APIs), supported by a number of the members of this WG. It has not  
been put up in a W3C document, if you mean that by a proposal. I have  
it on my plate and will get to it soon.

Nikunj
http://o-micron.blogspot.com

[1] http://en.wikipedia.org/wiki/Isolation_%28database_systems%29

Received on Friday, 24 July 2009 22:32:35 UTC