- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 24 Jul 2009 01:24:59 +0000 (UTC)
- To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
- Cc: public-webapps WG <public-webapps@w3.org>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>
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 01:25:36 UTC