Re: [WebStorage] Concerns on spec section 'Processing Model'

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

Received on Friday, 24 July 2009 21:20:03 UTC