Re: computational model of transactions

From: David Cressey <dcressey_at_verizon.net>
Date: Sun, 06 Aug 2006 13:08:44 GMT
Message-ID: <wRlBg.1552$Fl2.107_at_trndny01>


"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:1bbBg.1409$1f6.800_at_newssvr27.news.prodigy.net...

> A compiler can tell the difference between x = 10 and x = x + 5, why can't
a
> dbms?

Sure a compiler can tell the difference, but a compiler doesn't actually perform the operation. It generates code that, when executed, performs the operation. When the resulting machine code gets executed, the difference in intent between
the two operations you state may not be obvious at all.

Not so long ago, (perhaps before you were born) the main memory of computers was based on cores, little ferrite toruses. Reads were ALWAYS destructive in that implementation. Hence core memory controllers always operated in a read-pause-write mode. At the level of the cores themselves, you would have been hard put to tell the difference between three flavors of writes: the replacement and the modification you have been discussing, and a third. The third flavor of write is where the old value is being rewritten beck to the cores, because the read wiped them out.

My purpose in writing the above is not to wax lyrical about core memory, but to broaden your perspective. Just as there are multiple levels of interpretation and execution in a compiler, in a CPU and in a memory subsystem, so likewise there are multiple client-server levels of collaboration between quasi autonomous agents within a database server.

And a database server is only one part of a dbms. Received on Sun Aug 06 2006 - 15:08:44 CEST

Original text of this message