Yo.!andsmНо все же это не отменяет того, что при решении проблемы консистентности версионность в OLTP системах можно использовать только там, где нет требований к времени прохождения транзакций.
вам бы проспаться. крупнейшие OLTP системы мира крутятся на версионном оракле. посмотрите TPC-C. уж тут то вроде блокировочным режимам все карты в руки, мелкие транзакции, транзакции не сталкиваются друг с другом. казалось бы идеальные условия для блокировочников и сплошные неудобства ораклу с его консистентным RC и расходами на UNDO. но в тестах, чего то стабильно заруливает версионный оракл, а не блокировочники
http://oraclemind.blogspot.com/2006/11/tpc-c-oracle-10-vs-mssql2k5.html
Давно не читал спецификации TPC-C, но насколько помню там есть запросы где MSSQL использовал serializable IL. Соответственно наверняка это приводило к блокировкам.
Т.е. там опять таки не получилось менее ресурсоемкого решения для консистентности данных.

Dimitry Sibiryakovandsmэто не отменяет того, что при решении проблемы консистентности версионность в
OLTP системах можно использовать только там, где нет требований к времени прохождения
транзакций.
Не забывай добавлять "на MS SQL 2008". От их способа реализации версионности через
жопу tempdb ничего другого ожидать и не приходится.

С другими серверами не сравнивал, но что-то сомневаюсь что в Firebird реализовано лучше или хотя бы на таком же уровне.
Dimitry SibiryakovPS: Слова "консистентность" и "Read Committed" в одном предложении вообще звучат смешно.

Да это непросто, но реализуемо.