Не пойму сути компонентов а-ля TTransaction

← →
Игорь Шевченко © (2009-06-10 17:56) [40]

> В противном случае апи сервера состояло бы из одной функции
> function ExecStmt(Stmt: string): string; {в строке результата
> - информация об ошибке}

Собственно, так оно и есть. В большинстве случаев основные API - это Exec и Fetch, так как Exec должен откуда брать параметры в случае параметризованных запросов, добавляется Bind, так как Fetch должен куда-то класть то, что он нафетчил, добавляется Describe. Собственно, все.
Еще Connect и Disconnect.

Некоторые серверы реализуют отдельные вызовы управления транзакциями, типа BeginTransaction, Commit и Rollback, но это по большому счету излишне.
Говорю за те СУБД, с которыми более или менее знаком - Oracle, Interbase, ADABAS и за стандарт ODBC

← →
Пит (2009-06-10 18:35) [41]

> по моему убеждению все параметры нуно отдавать в формальном
> виде

сразу видно адепта строго типизированных ЯВУ )))

А вот какой-нибудь PHP"шник высказался бы по-другому.

Текстовое общение имеет ряд преимуществ. Многие очень используемые современные протоколы имеют именно текст-основу: тот же HTTP.

Преимущества в наглядности и доступности, недостатки в неэффективности (постоянный парсинг) и избыточности данных. Но с таким большим ростом вычислительных возможностей, памяти и прочего проблема все менее актуальна.

← →
PEAKTOP © (2009-06-10 18:43) [42]

> А я не пойму. Транзакция одна в контексте соединения, то
> есть TpFIBDatabase в данном случае. Это шо это получается,
> компонент TpFIBTransaction ставит в очередь все эти транзакции,
> или по надобности одну "резка" завершает, или как-то готовит
> активную для 2-хфазного коммита, или чего там происходит?

Все, что написано ниже, относиться к Firebird c учетом последней версии 2.5. Как там дела у Interbase позже версии 6.0 - не знаю.

Как вообще Джимом Старки все задумывалось: крутиться себе процесс (SuperServer или Embedded) или процессы (ClassicServer или SuperClassicServer) сервера. К нему есть подключения (имеющие свой ID) и транзакции (тоже имеющие свой ID). Отсюда правила:
1) Каждое подключение може иметь N транзакций, где N-инкрементальное число от 0 для последнего restore файла базы данных до предела типа данных LongInt (в Delphi Int64).
2) Каждая транзакция может относится к M подключениям, где M - число типа LongInt (в Delphi Int64).
До конца этот механизм не был реализован в InterBase6.0, но позже путем добавлений feature requests в Firebird этот механизм был реализован на 100%.

То есть в рамках одного подключения ты можешь иметь до фига транзакций, причем у каждой может быть свой уровень изоляции.

В рамках одной транзакции у тебя может быть несколько подключений, например, как в Cross-Database запросах, когда ты внутри тела хранимой процедуры или триггера обращаешься к другой БД ( http://firebirdsql.su/doku.php?id=execute_statement) с параметром WITH COMMON TRANSACTION.

В рамках одной транзакции у тебя может быть вложенная транзакция, которая может выполняться с другим уровнем изоляции данных и блокировки данных. Например, когда ты внутри триггера или хранимой процедуры выполняешь некоторые действия в рамках другой транзакции (http://firebirdsql.su/doku.php?id=autonomous_transaction).

<OFFTOP>
Ув. pasha_golub, можно личный вопрос ? А во сколько ты родился ? Я в 10:00 утра.
День, думаю, уточнять не надо. =))
</OFFTOP>

← →
MsGuns © (2009-06-10 23:13) [43]

Первый полноценный скл-сервер, с которым пришлось работать, был ИБ (точнее ФБ 1.0). Быстро "привык" к транзакциям и был весьма раб "рулить" ими, благо сам сервер другого и не преждполагает.
Потом переехал на мсскл. Первое время в голове был "белый шум" с транзакциями ибо "рулить ими как в ИБ просто нельзя. После внятной и прозрачной концепции транзакций ИБ въехать в "мутную" неявную транзакцию мсскл было крайне сложно (может быть возраст сказался). Особенно меня колбасило от вложенности транзакция и неявных транзакций.

Но ничего, привык.

ИМХО, чтобы понять принцип транзакций сервера, нужно прежде всего "въехать" в его "виртуальность", т.е. способ представления данных БД для конкретного клиента (соединения).
Если ИБ есть версионник и хранит версии записей ДЛЯ КАЖДОЙ ТРАНЗАКЦИИ, то мсскл - блокировочник и "пасет" клиента в целом, т.е. коннект.

Возможно, написал коряво, но все-таки истина, ИМХО, где-то здесь ;)

← →
turbouser © (2009-06-10 23:21) [44]

> MsGuns © (10.06.09 23:13) [43]

> Потом переехал на мсскл.

+1 После ib/fb - сущий ужас :(

← →
Игорь Шевченко © (2009-06-10 23:29) [45]

MsGuns © (10.06.09 23:13) [43]
turbouser © (10.06.09 23:21) [44]

Что лишний раз подтверждает тезис о трудоемкости и часто бессмысленности написания приложений, абстрагированных от СУБД (дескать, чуть слой доступа к данным подкрутим и все будет работать). Фиги. Не будет или не все или не так, как хотелось. Разумеется, речь не идет о тривиальных приложениях.

← →
MsGuns © (2009-06-10 23:39) [46]

Была статья в свое время Акопьянца "Блеск и нищета клиент-серверных технологий" - она в свое время направила меня на путь истинный.

Сегодня она висит у нас в отделе на самом видном месте. Каждого нового сотрудника первым делом заставляю штудировать и читать до полного проникновения.

← →
MsGuns © (2009-06-10 23:40) [47]

Кстати, а ведь жив, курилка ;)

http://www.computerra.ru/offline/1999/302/3766/print.html

← →
Игорь Шевченко © (2009-06-10 23:54) [48]

MsGuns © (10.06.09 23:40) [47]

Благодарю. А можно ссылки на остальные части ?

← →
MsGuns © (2009-06-11 09:14) [49]

Вечером отправлю тебе полную статью по почте, ежели твое мыло актуально
С работы сделать этого не могу ибо тут свои правила :)

← →
TIniFile (2009-06-11 09:26) [50]

> А можно ссылки на остальные части ?

http://akop.ru/personal/1856

← →
vuk © (2009-06-11 11:29) [51]

В статье ни одного откровения, из-за которого её стоит вешать на стенку, не обнаружил. А часть про организацию пользовательского интерфейса вообще, по большей части, из бреда состоит, особенно там, где про редактирование данных написано.

← →
PEAKTOP © (2009-06-11 11:43) [52]

> Если ИБ есть версионник и хранит версии записей ДЛЯ КАЖДОЙ ТРАНЗАКЦИИ

Это есть не совсем так. Все зависит от уровня изоляции транзакции и того, что эта транзакция делает (только чтение или чтение/запись). Давайте рассмотрим варианты.

Вариант № 1: транзакция isc_tpb_read_committed + isc_tpb_read, то она только читает данные с сервера и на сервере не создаются новые версии записей. При этом:
1) если в параметрах стоит isc_tpb_rec_version, то будут читаться данные от самой последней закоммитченной транзакции.
2) если же будет установлен isc_tpb_no_rec_version, то будет читаться самая последняя версия записей, даже если она принадлежит еще незакоммитченной транзакции.

Вариант № 2 и 3: транзакция isc_tpb_concurrency+isc_tpb_read (еще ее называют SNAPSHOT), то старт ее единственной тоже не приведет к появлению новых версий записей. Зато если после старта этой транзакции стартанет другая (третья, десятая) с любым уровнем изоляции (кроме isc_tpb_read_committed+isc_tpb_read), то версии записей будут плодится как кролики, т.к. серверу нужно будет хранить версию записей на момент старта ЭТОЙ транзакции. А если эта транзакция еще будет и isc_tpb_concurrency+isc_tpb_write (это значение по-умолчанию, когда в любых компонентах доступа не заполнено свойство T<X>Transaction.Params:TStrings), то ко всем вышеперечисленным прелестям добавляются еще и возможные deadlock-и.

Вариант № 4: транзакция isc_tpb_consistency+isc_tpb_write. Лично я бы рекомендовал использовать этот уровень изоляции исключительно для операторов INSERT/UPDATE/DELETE и DDL, т.к. данная транзакция создает новую версию записей "палюбому". А элементарный SELECT * FROM TABLE_NAME (за звездочку в SELECT вообще надо бить молотком по пальцам) в рамках этой транзакции приведет к появлению новой версии записей для всей таблицы. А если в таблице 8-10 млн. записей, то... ну, вы понимаете... =)

Это я все к чему. Firebird версионник, но с настраиваемыми параметрами транзакций. Поэтому он может вести себя по-разному, в зависимости от случая. Из Firebird сделать M$ SQL получиться, для этого нужно использовать во всех наборах данных в свойстве T<X>DataSet.Transaction := T<X>DataBase.InternalTransaction, а свойство T<X>DataBase.InternalTransaction.Params выставить при старте приложения в isc_tpb_concurrency+isc_tpb_write. И мы получаем поведение блокировочника.

← →
Sergey Masloff (2009-06-11 11:49) [53]

PEAKTOP © (11.06.09 11:43) [52]
>2) если же будет установлен isc_tpb_no_rec_version, то будет читаться >самая последняя версия записей, даже если она принадлежит еще >незакоммитченной транзакции.

В FB нет (и надеюсь никогда не будет) dirty read

Эта опция читает последнюю ЗАКОММИЧЕНУЮ версию записи. Если после нее есть еще неподтвержденная версия то в зависимости от других параметров или ждем подтверждения/отката или если ожидание не установлено то выдается исключение

← →
PEAKTOP © (2009-06-11 12:02) [54]

> В FB нет (и надеюсь никогда не будет) dirty read

Вот, только что у Влада Хорсуна спросил - таки да. Вы абсолютно правы.

← →
Sergey13 © (2009-06-11 12:14) [55]

> [51] vuk © (11.06.09 11:29)

Все таки ей (статье) уже 10 лет. Тогда, ИМХО, многие истины еще не были азбучными.
Мне лично, при прочтении, было жалко, что не читал ее тогда.

← →
Игорь Шевченко © (2009-06-11 12:37) [56]

> Мне лично, при прочтении, было жалко, что не читал ее тогда.

Осталось понять, какие статьи надо читать сейчас, чтобы через 10 лет не жалеть:)

Статья неплохая, по меньшей мере она проясняет, что не надо делать, а это уже плюс. Я, например, ряд тезисов понял на собственных ошибках (за какое время:), путь безусловно верных и доходчивый, но довольно долгий :)

← →
Пит (2009-06-11 13:18) [57]

PEAKTOP, спасибо больше за пост [52] и Сергею за уточнение.

← →
sniknik © (2009-06-11 13:32) [58]

> Все таки ей (статье) уже 10 лет.
это да ... знать бы про нее раньше было бы подспорье в "войне" с TADOTable воспроизводящему десктопную идеологию (первое же "откровение" в статье, да еще с таким примером крушения банка), которую веду с 200x-ного года.
логики на словах у нас не воспринимают, но была бы ссылка на написанное... написанному почему то верят, наверное привычка со времен СССР.

да и остальное полезно, даже сейчас много непонимающих, вот например любой кто задал вопрос в базах и не указал тип субд/используемый к ней доступ, должен прочитать про идентичность.

и про аксесс... прослеживается развитие, тогда это значит было только "фичей" аксесса, ну то как он обновляет данные в связанных структурах (хотя я и не согласен, что не понятно, просто непривычно для IB-шника), а теперь это есть в ADO... похоже тренировались "на кошках". ;)

← →
sniknik © (2009-06-11 13:34) [59]

> должен прочитать про идентичность.
вернее про иллюзию идентичности в статье.

← →
Sergey13 © (2009-06-11 13:47) [60]

> [56] Игорь Шевченко © (11.06.09 12:37)
> Осталось понять, какие статьи надо читать сейчас, чтобы
> через 10 лет не жалеть:)

Лишь бы не инструкцию по сборке/разборке автомата. 8-)
Сейчас то все таки проще. Интернет есть уже практически везде - рой сколько угодно. А тогда, в конце 90-х, с этим было (особенно в провинции) ой как не просто. Да и книг в магазах было все таки значительно меньше. Поэтому путь проб и ошибок был практически единственным из доступных.

← →
vuk © (2009-06-11 14:02) [61]

to Sergey13 © (11.06.09 12:14) [55]:
>Все таки ей (статье) уже 10 лет. Тогда, ИМХО,
>многие истины еще не были азбучными.
Не, если сидеть под файлсерверными базами, то да, наверное не были. Я, насколько себя помню, тогда уже под MS SQL писал. И никаких иллюзий не было. Так что мне что тогда, что сейчас, ничего нового в той статье не открылось бы.

← →
sniknik © (2009-06-11 14:02) [62]

> Интернет есть уже практически везде
А помните голодные годы? Интернет по карточкам...

← →
sniknik © (2009-06-11 14:08) [63]

> И никаких иллюзий не было.
я тоже у себя подобных иллюзий не помню, но знаю кучу людей которым статья не помешала бы (хотя, большинство из этой кучи ее попросту не поймет :( ).

← →
Игорь Шевченко © (2009-06-11 14:08) [64]

vuk © (11.06.09 14:02) [61]

Я в те годы под Оракл и под Interbase писал. Но иллюзии были не сколько у программистов, сколько у потенциальных заказчиков. Может и мне нового не открылось бы, но в статье, на мой взгляд, все очень удачно собрано вместе.

← →
Игорь Шевченко © (2009-06-11 14:09) [65]

> А помните голодные годы? Интернет по карточкам...

а за каждой карточкой 5 км в гору зимой по гололеду

← →
Игорь Шевченко © (2009-06-11 14:15) [66]

И вообще - транзакции, фигакции, пустое это все.
Вот как надо делать системы:

http://www.sql.ru/forum/actualthread.aspx?bid=9&tid=669844&pg=1

← →
pasha_golub © (2009-06-11 14:24) [67]

>
> <OFFTOP>
> Ув. pasha_golub, можно личный вопрос ? А во сколько ты родился
> ? Я в 10:00 утра.
> День, думаю, уточнять не надо. =))
> </OFFTOP>
>

Полдень.

← →
Sergey13 © (2009-06-11 14:27) [68]

> [61] vuk © (11.06.09 14:02)
> Не, если сидеть под файлсерверными базами, то да, наверное не были.

А я тогда как раз с Клиппера на Делфийского Оракула переползал. С трудом.

Для мозгов переползание с файлсерверного чуда трудно дается. По себе помню. Буря прямо внутре.

> А я тогда как раз с Клиппера на Делфийского Оракула переползал. С трудом.
> Для мозгов переползание с файлсерверного чуда трудно дается. По себе помню. Буря прямо внутре.
да бросьте, нормально с фохпро на первасвиль "пересел".
сначала непривычно было, и только то, что нельзя напрямую таблицу отрыть/индекс ей назначить (начал естественно с этого), но как только "дошло", что работая с сервером работаешь не с самими таблицами, а по сути с другим приложением "дошло" и то, что все это совсем совсем другое и надо не "пересаживаться", а изучать новое. и в общем то все, "буря" кончилась, не начинаясь, буквально при первом прямом знакомстве (читал про сервер первасвиля, пока он у меня не появился, несколько дольше, но "осознания" этого простого факта не было, пока сам не "пощупал").
кстати потом это понимание, перенес и на компоненты ADO которые борланд делал именно для переходя с BDE (десктоп в основном) программ, ратуя за то, чтобы их убрать, а к ADO относится как к новому, и изучать именно то, что он есть, его родные компоненты, а не "привычные переходники" (старые привычки = новые глюки в новом).

to Игорь Шевченко © (11.06.09 14:08) [64] :
>Но иллюзии были не сколько у программистов, сколько
>у потенциальных заказчиков.
Потенциальный заказчик, начитавшись такого, скорее всего сделает вывод, что серверные БД - дерьмо и развод лохов на баппки. :)

Во как задела статья :)

Почему на стене объясню.

Практически 100% приходящих выпускников и практикантов (дипломников) нашего политеха имеют типичное файл-серверное мышление, старательно втоптанное в их чистые светлые головы преподавателями - "мастерами". Бороться с которым (мышлением) в одиночку ох как тяжко. А тут тнкул носом в стену, дал срок неделю-другую для воплощения прочитанного - и проверяй результат.
Как показывает практика - весьма эффективная метода.

Мне кажется, что подобная ситуация далеко не редкость. Более того, встречается чуть ли не повсеместно.

vuk © (11.06.09 16:28) [71]

Потенциальный заказчик таких статей не читает. Потенциальный заказчик, хочет, чтобы его задачи решались в приемлемое время. А исполнители заказчика хотят, чтобы был приемлемый отклик. Когда им объясняют, что приемлемый отклик будет за счет отсутствия привычных удобств (в ряде случаев), у них начинается внутренний конфликт. Иногда заказчик игнорирует мнений своих исполнителей, иногда нет :)

> Практически 100% приходящих выпускников и практикантов (дипломников)
> нашего политеха имеют типичное файл-серверное мышление,
> старательно втоптанное в их чистые светлые головы преподавателями
> - "мастерами"

+ 1 000 000

-- Как я Вас понимаю...
-- Нет, Вы не понимаете...
-- Я отлично Вас понимаю...
.......
(с) Реклама по ящику

Обратное "размагничивание" мозгов выпускников - это отдельная тема. И очень даже не юмора. Особенно когда их старательно "намагничивали" в течение пяти лет придурки, оставшиеся на уровне развития технологий середины 90-х годов. У нас в провинции это особенно актуально.

to PEAKTOP © (11.06.09 16:51) [74]
>Особенно когда их старательно "намагничивали"
>в течение пяти лет придурки, оставшиеся на уровне
>развития технологий середины 90-х годов.
А, собственно, кто мешал этим выпускникам самим поинтересоваться, что же там нынче на дворе происходит? Их в яндексе поголовно забанили?

> кто мешал этим выпускникам самим поинтересоваться

Да кто его знает...
Но, как говорил первый президент Украины Л.М.Кравчук "Имеем то, что имеем..."
В условиях 200 000 города с единственным ВУЗом, готовящим по специальности, выбирать особенно не приходится.

Приходится "перезатачивать" !
=))))

>vuk © (11.06.09 19:20) [76]
>А, собственно, кто мешал этим выпускникам самим поинтересоваться, что >же там нынче на дворе происходит? Их в яндексе поголовно забанили?

Я, конечно, извиняюсь, но..
Такое впечатление, что Вы учились в Массачусетском технологическом ;)

Я вот учился вообще не по программированию, и как ни странно, Яндекса в то время ну нифига не было. И за каждой книжкой в библиотеку по 5 км в гору зимой по гололеду, да еще очередь отстаивать. И неплохо, надо признать, при всем при этом выучился программировать.

Так веь на одного Шевченко триста тридцать три Ковалей и Петренок ;)))

Не пойму сути компонентов а-ля TTransaction Найти похожие ветки