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