SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Oracle Corporation (ORCL) -- Ignore unavailable to you. Want to Upgrade?


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