To: AnnieK who wrote (7242 ) 6/1/1998 10:13:00 AM From: Michael Olin Respond to of 19080
Your explanation of read-consistency is almost perfect. Read-consistency guarantees that a user's view of the database does not change during a transaction. For example, if I query an order and another user changes the same order and commits their changes, my transaction still sees the old data. In Oracle, if I try to change the order, I will be told that it was changed by someone else and prompted to requery to get the new values. If I don't try to change the data, I still see the old values until my transaction finishes. Some systems will automatically update a user's view of a record once another user has committed a change to it. This does not maintain read-consistency. As far as row-level locking goes, the situation was not quite as bad as locking at the table level (depeding on which DB server you used). Data in a database is stored on logical "pages" which generally are sized to take advantage of how the underlying hardware moves data in and out of memory (in Oracle, page size is set at the time of database creation and can be changed depending upon the hardware setup). Since a page can contain more than one row of data, database servers that did not lock at the row level locked the page, locking all of the data on the page that the modified row was on. Depending on how the data in the database was physically arranged onto pages, updating an order could lock another order or even an unrelated customer record that happened to reside on the same page as the order being updated. Row-level locking was (is) a big advantage in allowing increased throughput without putting the integrity of the database at risk. -Michael