- From: Aaron Boodman <aa@google.com>
- Date: Fri, 24 Jul 2009 14:37:53 -0700
- To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
- Cc: Ian Hickson <ian@hixie.ch>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>, public-webapps WG <public-webapps@w3.org>
On Fri, Jul 24, 2009 at 2:17 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com> wrote:
>
> 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.
It's not clear to me what you're asking about in this paragraph. Write
transactions should be exclusive, read transactions can be shared.
Write transactions queue until all open read transactions complete.
I can't find the actual spec right now (where is its canonical home
now?) so I can't point at the exact text, but that is the goal I
believe.
>> 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
In these cases, the developer caused the exception himself, and it
only affects his own application. So it's not unexpected in the same
sense locking exceptions are.
> 3. face a disk failure
Yes, but there is nothing that the platform can do about this case. It
is an exception in the truest sense of the word.
> 4. encounter a bug in the underlying software
The platform shouldn't have API just in case underlying software has
bugs. Throwing an exception and unwinding the transaction is the most
sensible thing to do and what it does now.
> In either of these cases, how would the application code be expected to
> recover?
It can't, but these are exceptional circumstances that are generally
unexpected and indicate bigger problems. This is different from access
conflicts which are expected and do not indicate bigger problems. The
platform can and should make this easier.
>> 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 am also interested in a non-SQL storage API, but I think this is a
separate issue.
>> 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?
I think you are either misunderstanding the spec or it has a bug,
because this is not the intent. Requests to obtain read/write
transactions are asynchronous and are queued until they can be
granted:
myDatabase.transaction(function(tx) { // this callback doesn't occur
until the caller has exclusive access
});
- a
Received on Friday, 24 July 2009 21:38:33 UTC