On Jul 24, 2009, at 1:36 AM, Ian Hickson wrote:
On Fri, 24 Jul 2009, Laxmi Narsimha Rao Oruganti wrote:
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.
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.
Can you explain "a more serious bug"? The write lock may actually
happen in the middle of a read-only transaction, can't it? I don't see
spec text prohibiting that.
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.
Even if you have a transaction lock,
1. the application logic could cause an exception
2. the application finds an unacceptable data condition and needs to
rollback the transaction
3. face a disk failure
4. encounter a bug in the underlying software
In either of these cases, how would the application code be expected
to recover?
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?
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.
We can't be firing unexpected exceptions when their users
happen to open two tabs to the same application at the same time,
leaving
data unsaved.
So you'd much rather tell an application user that they should close
one of the two tabs since they can't obtain a read-write lock in both.
I still don't understand how the exclusive database lock helps. Would
you please elaborate?
This is no different from telling the user that undesirable things
would happen if they hit the back button, which was widely prevalent
in applications used from Web browsers not too long ago. And those
programmers knew nothing about HTTP. The solution was - knuckle down
and understand safe and unsafe methods and statelessness.
Nikunj
http://o-micron.blogspot.com
