Re: [WebStorage] Concerns on spec section 'Processing Model'

The spec should not restrict implementations to any one level of  
concurrency unless there are specific undesirable effects.

Restricting the database to a single writer means that if there are  
separate workers or background threads working to update non- 
overlapping portions, then they have to wait for the lone current  
writer. Implementations can certainly compete to produce the level of  
concurrency that developers need. Specifically, I propose that the  
following text
[[
If the mode is read/write, the transaction must have an exclusive  
write lock over the entire database. If the mode is read-only, the  
transaction must have a shared read lock over the entire database. The  
user agent should wait for an appropriate lock to be available.
]]

be replaced with the following text

[[
Multiple read-only transactions may share the same data as long as  
there is no transaction attempting to write the  data being read. The  
user agent must wait for transactions that are reading some data  
before allowing a read/write transaction on the same data to continue.
]]

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



On Jul 16, 2009, at 6:46 AM, Laxmi Narsimha Rao Oruganti wrote:

> [Adding the subject, sorry for spam!]
>
> Hey folks,
>
>                 I have few questions on Web Storage Spec.  I have  
> checked the content of both latest published spec and  latest  
> editors spec.  And the questions are applicable to both the versions  
> of the spec.
>
>                 Section: 4.4.2 Processing model
>                 Text:
> 1.       Open a new SQL transaction to the database, and create a  
> SQLTransaction object that represents that transaction. If the mode  
> is read/write, the transaction must have an exclusive write lock  
> over the entire database. If the mode is read-only, the transaction  
> must have a shared read lock over the entire database. The user  
> agent should wait for an appropriate lock to be available.
>
> Concerns:
> -          Why is the spec mandating a transaction to take an  
> *exclusive write lock on the entire database*?  No database book  
> design mandates it.  In fact, many client databases out there don’t  
> do this.  I guess SQLite does this kind.  But that does not mean  
> that all implementations have this nature.  I am kind of worried  
> that we are putting implementation in theory.  For me they are too  
> separate, there are many ways a database could be designed.  Like,  
> log+checkpoint approach,  shadow copy, version store, journals … 
> etc.  I guess spec should say what a browser should do and not how.
>
> I would be happy to get enlightened.
>
> Thanks,
> Laxmi
>
>
>