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

That is all the responsibility of database system.  We don't need to tell database systems on how to do it, we just need to tell them on what to do.  Today database systems do have lock manager which takes care of these responsibilities.  

Coming to the question of failing transaction unpredictably, even with current specification; transaction do fail.  For example, if there exists a writer transaction which is already holding an exclusive lock, this new thread would fail to acquire lock.  The failures would be there.

Now the next question people would ask is on how do we make sure that partial changes are not causing problem in case of a failure in the middle of sequence of operations.   That is the responsibility of transaction manager.   Note that transaction manager treats the whole sequence as a single atomic unit.  

Are we missing something?

Thanks,
Laxmi 

-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch] 
Sent: Friday, July 24, 2009 6:55 AM
To: Nikunj R. Mehta
Cc: public-webapps WG; Laxmi Narsimha Rao Oruganti
Subject: Re: [WebStorage] Concerns on spec section 'Processing Model'

On Thu, 16 Jul 2009, Nikunj R. Mehta wrote:
>
> 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.
> ]]

Since there's no way for the author to say ahead of time which rows or cells the transactions are going to use, how can you do the above without ending up with some transactions failing unpredictably?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 24 July 2009 07:15:17 UTC