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
