Re: Theoretical Basis for SELECT FOR UPDATE

vc wrote:
> ... and says, "For the record, the final "a" value for id = 1 in table
> tb1 will be 90". This quote implies that: 1) the statements inside the
> multiple assignment are executed strictly sequentially and '90' is
> assigned by the last update; 2) 'update tbl set a=250' and 'update tbl
> set a=90' do *not* conflict with each other.

Yes, it does - I just noticed that myself on re-reading the post. However, I am pretty sure that conflicts with what I read in the other paper. I can't check at the moment, but I was reading that yesterday and I'm sure it used the term "parallel" w.r.t. processing of multiple assignments - which I took to mean "not sequential".

> This feature is interesting because in fact it implies that the
> hypothetical database has to implement multiversioning. How else can
> it get the last consistent value of 'a' after 'a' has already been
> changed ? This would exclude from consideration all purely locking
> databases similar to DB2, SQL Server, Informix, Sybase, etc.

Well I suppose the DBMS could gather all the data it will need before it changes any and store it temporarily somewhere? Multiversioning just makes it easier and more efficient, I think. Received on Wed Oct 05 2005 - 18:11:10 CEST