Oracle
1. Non-escalating row-level locking
In the days of yore, locking was managed at a variety of levels. Whenever you did an update, Oracle would lock all the rows on that physical data block. As more and more updates were performed, more and more blocks would get locked. Eventually the list of locked items would reach a threshold and Oracle would "promote" (escalate) the lock... instead of having locks on 10,000 data blocks (for example), Oracle would "promote" the lock - locking the entire table. After the lock was "promoted" instead of 10,000 entries to check, there would be only one. Now, you can explicitly lock the entire table, or you can let Oracle manage the locking at the lower (row) level.
2. Multi-version read consistency.
Imagine this scenario. User U accesses a table, reading and updating various rows and columns. After an update, if s/he re-reads an updated row, Oracle will return the updated value. No big surprise there. Even if U has not performed a commit, their selects will reflect the updated values.
Here is the trick. Let's say user R reads from the table, and s/he starts after U has performed some updates, but has not performed a commit (yet). The values R will see will reflect the values in the rows and tables from BEFORE U performed any updates. So, U and R will see consistent sets of values in their selects, but each will return a different "version" of the table - U's with the uncommitted changes applied, R without the uncommitted changes made by U.
3. Concurrency.
Concurrency allows multiple users to access the same object at the same time. Even after user U has performed updates to a row - either committing the changes or not - user R was able to read the same rows. The two users were able to "concurrently" access the same rows at the same time.
Click here
0 Comments:
Post a Comment
<< Home