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

Let me probe this further to get clarity.

[Ian]  >> 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. 
[Ian]  >> 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.  

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.  

I have a question:
- Many of the database systems today don't ask the user to specify the purpose of use (read/write) when opening a transaction.  But the spec is expecting to specify the use of transaction for read/write.  If we really need this to fly with multiple database systems, we should start that type of choice at connection opening time and not at transaction creation time.  A connection typically accepts read/write or read only connection.  Nikunj or others should comment on whether taking read/write Vs read-only choice at connection time is practiced in their corresponding products.  


Thanks,
Laxmi

-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch] 
Sent: Friday, July 24, 2009 2:07 PM
To: Laxmi Narsimha Rao Oruganti
Cc: Nikunj R. Mehta; public-webapps WG
Subject: RE: [WebStorage] Concerns on spec section 'Processing Model'

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. 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.

I think this is an important invariant, because otherwise script writers _will_ shoot themselves in the foot. 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. 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 24 July 2009 09:43:26 UTC