zVlad wrote:Мне показалось, что те статьи были вовсе не о транзакционных механизмах.
Кстати, халтура - недобросовестная работа, выдача одного за совсем другое, иначе - ложь, обман. Не могли бы Вы, Tengiz, открыть мне глаза и указать на ложь (обман), имеющие место быть в тех статьях.
В тексте по ссылке sp123, раздел Concurrency Control:
1 - страница 50, первый абзац из Concurrency and Locks: "For both Oracle and DB2, a transaction is an atomic unit of work, in which all changes are either committed or rolled back. However, while both DB2 and Oracle have row-level locking (as opposed to page-level locking, as in SQL Server), there are differences in when the locks are acquired."
Ложь и обман: в статье 2002 года писать о page-level locking в SQL Server.
2 - страница 50, последний абзац из Concurrency and Locks: "Due to these differences, ported applications that have updaters and readers accessing the same data concurrently from the same table may experience more lock wait time in DB2, but with a more consistent view of the data."
Искажение: у автора довольно своеобразное нестандартное представление о том, что такое consistent view.
3 - страница 50, середина третьего абзаца в Isolation Levels: "For example, when an Oracle application starts an update transaction, the old version of the data is kept in the rollback segment. When any other application makes a read request for the data, it gets the version from the rollback segment. Once the update transaction commits, the rollback segment version is erased and all other applications see the new version of the data."
Ложь и обман: версии не удаляются из rollback segment при окончании транзакций из создавших.
4 - страница 50, четвёртый абзац в Isolation Levels: "To ensure read consistency in Oracle, the application must issue SELECT FOR UPDATE. In this case, all other readers and updaters are blocked."
Ложь и обман: следствие уже рассмотренного искажения, описанного в пункте (2).
5 - страница 51, пятый абзац с конца в Isolation Levels: "Oracle's implementation most resembles Read Stability (RS) in DB2 UDB for writers and most resembles Uncommitted Read (UR) for readers."
На такое ученику в школы бы сказали: "Ich gehbe dir die Note Zwei" или просто - "Садись, два".
6 - страница 51, четвёртый абзац с конца в Isolation Levels: "With the exception of UR transactions, DB2 UDB can guarantee that the data an application reads does not change under it. "
Ложь и обман: автор не сказал, что не только UR но и CS не гарантирует, что данные (для CS кроме тех, на которых находится курсор), прочитанные в транзакции могут быть изменены другими транзакциями.
7 - страница 52, конец второго абзаца в Lock Escalation: "Oracle does not have the concept of lock escalation; the application is blocked if there is insufficient memory to acquire the lock."
Не правда и не ложь, что на самом деле даже ещё хуже, потому что похоже на правду. С одной стороны, согласно материалов IBM - ORACLE хранит информацию о блокировках на диске, с другой стороны, почему-то может не хватить памяти на блокировки? На самом деле всё несколько сложнее - а упрощение здесь хуже вранья.
8 - страница 52, четвёртый абзац в Deadlock: "Oracle does not have a deadlock detector to resolve deadlocks. Applications can use the NOWAIT clause or set a time-out for the session to avoid deadlocks."
Ложь и обман в чистом виде.
9 - страница 53, первый абзац в How to Improve Concurrency: "To maximize concurrency in DB2 UDB, keep the following in mind:... - Use Uncommitted Read (UR) and Cursor Stability (CS) whenever possible."
За одно только это статью можно сразу засовывать в шреддер.
И это всего лишь на 4 страницах.
