Hello, Nikolay!
Nikolay Ponomarenko wrote:
Кстати, а если абстрагироваться на более высокий уровень - хотя бы самого
соединения с БД и сокета - ведь для задачи ПАРАЛЛЕЛЬНОСТИ несколько
транзакций никак не применимы - все равно ведь они будут сериализованы,
пусть даже и на транспортном уровне, хотя конечно и уменьшат время реакции.
блин, ну элементарно же. Давайте представим что у нас 1 транзакция
на соединение. Грубо говоря, есть 1 IBDatabase который в себе содержит
IBTransaction. В результате придется или работать постоянно в
commitretaining, или взять и положить столько IBDatabase сколько надо.
Допустим, если бы так и было, кто-нибудь замордованный таким фактом
придумал бы специальный IBDatabase, который бы сам открывал новый
коннект на новую транзакцию.
И это разумеется не ради параллельного выполнения операций, а просто
ради удобства.
Если я правильно понимаю блокировочные сервера, то длительная работа
любых транзакций (кроме dirty read) нежелательна по ресурсам
и блокировкам. Поэтому есть привычка к короткоживущим транзакциям,
буквально на пару тройку операторов. В версионнике нет смысла
жаться в этом плане. Можно себе позволить более долгие транзакции.
Вот и вся разница, на мой взгляд.
Остается только случаи необходимости именно _транзакционности_ некоторых
псевдо-параллельных действий, так?
тут ведь еще есть вот какой момент. Любовь к "параллельным" транзакциям
пошла из-за того, что BDE а потом и FreeIBComponents, и IBX/FIBPlus
убивают кэш в датасетах, т.е. "закрывают запросы".
Именно отсюда возникла необходимость иметь возможность долго держать
открытыми датасеты, и одновременно стартовать и завершать транзакции
с другими датасетами.
А функциональность сервера это уже позволяла.
Дальше появился TClientDataSet, который мог держать кэш (рекордсет)
даже в случае закрытия коннекта. Только он не очень прижился.
Кстати, а кто знает, какие еще сервера умеют несколько транзакций в одном
коннекте?
В оракле можно что-то эмулировать автономными транзакциями, но нормальных - нет.
А как в DB2, Postgress, MySQL, Sybase SQL Server, SQL Anywhere?
фиг знает. насколько я в курсе, стандартная архитектура почти всех
драйверов, особенно поддерживающих массу серверов, это
один коннект+транзакция -> много датасетов.
так получилось исторически, из-за влияния масс.
На мой взгляд это было так - сервером управляли командами
SQL. START TRANSACTION, FETCH и так далее.
Например в SELECT воткнуть информацию к какой он транзакции относится -
некуда. Значит надо уметь переключать "контекст транзакции" в коннекте.
А для этого надо помнить на сервере транзакции, стартованные клиентом.
А нахрена париться, когда можно сказать - "один коннект - одна
транзакция - один рекордсет" - и все.
А если над этим навешивать драйвер, то и тут нескольким транзакциям
на коннект неоткуда взяться. И т.д.
То есть, все дело привычки и архитектуры. Нет версионности -
тогда или dirty read или сериализация или блокировки. Есть
версионность - тогда snapshot. Есть n транзакций в одном коннекте -
на здоровье. Нет - открываем n коннектов (или вообще этим не занимаемся).
Кстати, на sql.ru в "Сравнении СУБД" регулярно возникает
вопрос "умерли РСУБД или нет". Какое тут умерли, если до сих пор
баталия между версионниками и блокировочниками идет.
Можно сказать, что у РСУБД есть еще нераскрытый потенциал архитектур. :-)
p.s. что-то я не очень то ответил на rsdn. если хотите, можете
и это письмо туда форварднуть или процитировать.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
