Здравствуйте, Andyshark, Вы писали:

A>Хм. А я где-то говорил что я СТОРОННИК BDE? Но я сторонник того что идея то была более-менее хорошая.
Для примерно так двенадцатилетней давности. Сейчас — скорее глупость.

A>Если бы она была совсем дерьмовая, то она бы уже давно умерла.
Так ведь умерла.

A>Или вы считаете всех кто пользует BDE придурками и дерьмохлебами? Сразу скажу — я BDE уже сто лет не пользую, ну не сnоронник я ее в чистом виде. Но для своего времени это было очень даже и неплохо. Можете отделить идею от реализации? И учетом того КОГДА идея была сделана?
Если сейчас явно строить новые приложения на BDE — то это уже что-то странное. Естественно, поддержка старых приложений и legacy-систем — это отдельный вопрос.

Здравствуйте, Andyshark, Вы писали:
A>Хм. А я где-то говорил что я СТОРОННИК BDE? Но я сторонник того что идея то была более-менее хорошая. Если бы она была совсем дерьмовая, то она бы уже давно умерла.
Факт, умерла.
A> Или вы считаете всех кто пользует BDE придурками и дерьмохлебами? Сразу скажу — я BDE уже сто лет не пользую, ну не сnоронник я ее в чистом виде. Но для своего времени это было очень даже и неплохо. Можете отделить идею от реализации? И учетом того КОГДА идея была сделана?
Могу. Идея — отвратительная. Да, в то время это было неочевидно. Еще вопросы?

Здравствуйте, Andyshark, Вы писали:
A>>>Про сырые данные которые может прочитать транзакция в IB/FB. Откуда они могут появиться? Вы то хоть сами поняли что сказали? Может пример приведете, хоть на пальцах?
S>>Тебе же написали — сырые данные поставляет клиент. Одной рукой он пишет в T1 некие данные, читает что-то там из T1 и второй рукой пишет в T2. С точки зрения T2 эти данные являются сырыми, потому что коммита T1 еще не произошло. Если T1 откатить, а T2 закоммитить, то в базе окажется результат никогда не существовавших вычислений.
A>Я наверное не догоняю, но ткните меня пальцем ГДЕ клиент поставляет мне сырые данные?
Я написал. Все результаты изменений, сделанных в одной транзакции, будут сырыми данными для другой. Именно поэтому сервер не даст второй транзакции "увидеть" эти изменения.
Но клиент может перенести их руками.

A>То что у меня на одной форме два запроса работающих в разных транзакциях (причем один селект, а другой на апдейт к примеру), то где тут сырые данные скажите мне?
A>Первый возвращает гарантировано закоммиченные данные
Кто тебе сказал? Вот тебе простой сценарий:
T1:

update table1 set data = data + 100 where ID = 1
select data from table1 where ID=1

Вот мы вроде бы почитали данные в транзакции 1. Допустим, получилось 150.
И тут же, не дожидаясь коммита, в совершенно другой транзакции мы пишем

update table2 set data = 150 where id=1

вот эти 150 — это сырые данные. Семантика запроса вроде бы такая ж, как если бы мы напрямую написали

update table2 set data = (select data from table1 where id=1) where id=1

Но в таком раскладе нам СУБД не даст выстрелить себе в ногу. В зависимости от архитектуры сервера и выбранного уровня изоляции такой апдейт либо заблокируется в ожидании коммита T1, либо скопирует "старое" значение из table1. В итоге, всё останется согласованным.

Но в описываемом варианте программист ловко обходит защиту и пишет 150 в T2. Если выполнить T1.Rollback, то в базе останется значение, посчитанное непонятно откуда.

A>, второй гарантировано пишет. Никаких блокировок тем более не происходит. Если мне они нужны будут на какой-либо записи то я ее сделаю самостоятельно (или помощью запроса соответствуюего, но это уже по мере необходимости). Видно имеет место БОЛЬШОЕ недопонимание логики работы других людей, которые работают с более расширенным функционалом.
Никакого непонимания нет. Увы. Я работал с СУБД с 12 лет. Термин "РЕБУС" что-нибудь говорит? И с т.н. "более расширенным" функционалом, и с менее расширенным.
A>И хочется загнать их в эти рамки. Кто вам сказал что я не могу использовать оба запроса в одной транзакции? Могу. Но по некоторым причинам не хочу в данном конкретном случае. Кто сказал что я не пользуюсь одной транзакцией для задачи? Я такого не говорил, я пользуюсь. Но в каждом конкретном случае рассматриваю КАК мне лучше сделать доступ к БД. Мало ли какая задача.
Доступ к БД — это техническая подробность. У наших пользователей есть очень много потребностей. Нам надо думать о них, а не о том, по сколько транзакций открывать в одном соединении. Грамотная платформа обязана изолировать разработчика от этих кишочков, причем достаточно безболезненно. В том смысле, чтобы это не достигалось ценой, к примеру, просада производительности или ограничениями масштабируемости.

A>Вот кстати еще одна в которой неудобно использовать одну транзакцию:
A>Есть таблица в которой присутствуют записи должные быть распечатанными один единственный раз на некоторых принтерах (не будем вдаваться в каких, не суть важно). Т.е. в данном конкретном случае мы имеем с одной стороны БД целостность которой должны быть поддержана в любых условиях. С другой стороны повторная печать на принтере не допускается. Т.е. из этой таблицы данные должны удаляться (помечаться на удаление) после печати. Если я стартую все в одной транзакции, то мне туда же надо и запихивать удаление (пометку на удаление), и коммитить после каждой печати запрос на выборку. Ну и как данную задачу решить с одной транзакцией?
Ниче не понял. А в чем, собственно, проблема? Я четко вижу ровно одну транзакцию — выгрести и убить. Причем именно так: если выгребание по какой-то причине не удалось, то убивать нельзя, т.к. данные так и не доехали до принтера.
A>Легко скажете? А не легче ли стартовать snapshot транзакцию и не париться? Зачем лишний геморой? Я наверное не понимаю.
А чем вам поможет snapshot транзакция? Покажите мне, что делается в первой транзакции, и что во второй.

A>Вау. Бог и иже с ним. Я свою позицию по этому вопросы высказал. Проблема в том что Вы не хотите встать на позицию оппонента. Мне вас по человечески жаль.
Я на позиции оппонента уже стоял. Давно. По неведению.

Здравствуйте, Sinclair, Вы писали:

A>>То что у меня на одной форме два запроса работающих в разных транзакциях (причем один селект, а другой на апдейт к примеру), то где тут сырые данные скажите мне?
A>>Первый возвращает гарантировано закоммиченные данные
S>Кто тебе сказал? Вот тебе простой сценарий:
S>T1:
S>

S>update table1 set data = data + 100 where ID = 1
S>select data from table1 where ID=1
S>

S>Вот мы вроде бы почитали данные в транзакции 1. Допустим, получилось 150.
S>И тут же, не дожидаясь коммита, в совершенно другой транзакции мы пишем
S>

S>update table2 set data = 150 where id=1
S>

S>вот эти 150 — это сырые данные. Семантика запроса вроде бы такая ж, как если бы мы напрямую написали
S>

S>update table2 set data = (select data from table1 where id=1) where id=1
S>

S>Но в таком раскладе нам СУБД не даст выстрелить себе в ногу. В зависимости от архитектуры сервера и выбранного уровня изоляции такой апдейт либо заблокируется в ожидании коммита T1, либо скопирует "старое" значение из table1. В итоге, всё останется согласованным.

Этот пример показывает, что ACID сервер нарушить не даст.
Я может быть не совсем правильный пример привел. Но его идея была в том, что бы не делая коммита T1 видеть изменения, привенесённые T2. И все в рамках одного коннекта из одного потока.
Зачем это нужно — вопрос клиентского приложения.

A>>Вот кстати еще одна в которой неудобно использовать одну транзакцию:
A>>Есть таблица в которой присутствуют записи должные быть распечатанными один единственный раз на некоторых принтерах (не будем вдаваться в каких, не суть важно). Т.е. в данном конкретном случае мы имеем с одной стороны БД целостность которой должны быть поддержана в любых условиях. С другой стороны повторная печать на принтере не допускается. Т.е. из этой таблицы данные должны удаляться (помечаться на удаление) после печати. Если я стартую все в одной транзакции, то мне туда же надо и запихивать удаление (пометку на удаление), и коммитить после каждой печати запрос на выборку. Ну и как данную задачу решить с одной транзакцией?
S>Ниче не понял. А в чем, собственно, проблема? Я четко вижу ровно одну транзакцию — выгрести и убить. Причем именно так: если выгребание по какой-то причине не удалось, то убивать нельзя, т.к. данные так и не доехали до принтера.
Немного не так. Выгрести, попробовать обновить в другой транзакии, а результат увидеть в транзации выгребания.

P.S. Всё это обсуждалось, не касаясь конкретной предметной области.

Для предметных областей было приведено как минимум два примера:
1. Добавление клиента (T2) для изменяемого документа (T1)
2. Ведение лога работы пользователя (работа в T1, лог в T2)

Здравствуйте, IB, Вы писали:

SЗ>>Да хотя бы на это:
IB>И причем здесь "это"?
Как я понял, аргументов не будет?

IB>P. S.
IB>Никто тебя, кстати, не банил, не надо тут истерики устраивать и на публику работать.

Угу. Только вот почему-то в БД мессаги под моим аккаунтом не отправлялись, тогда как Test работал без проблем

Здравствуйте, SmlMouse, Вы писали:
SM> Этот пример показывает, что ACID сервер нарушить не даст.
Ага.
SM> Я может быть не совсем правильный пример привел. Но его идея была в том, что бы не делая коммита T1 видеть изменения, привенесённые T2. И все в рамках одного коннекта из одного потока.
Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.

SM> Зачем это нужно — вопрос клиентского приложения.
Зачем — это вопрос философии. А мы находимся в СВ, т.е. еще дальше от практики. Технические детали велком в форум Базы Данных. А здесь мы обсуждаем вопросы веры отдельных товаришей в то, что некоторые порицаемые другими товарищами практики иногда могут иметь практический смысл.

SM>Для предметных областей было приведено как минимум два примера:
SM>1. Добавление клиента (T2) для изменяемого документа (T1)
Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.

SM>2. Ведение лога работы пользователя (работа в T1, лог в T2)
То же самое. Ведите лог через отдельное соединение. Чему это противоречит?

Здравствуйте, Sinclair, Вы писали:

SM>> Я может быть не совсем правильный пример привел. Но его идея была в том, что бы не делая коммита T1 видеть изменения, привенесённые T2. И все в рамках одного коннекта из одного потока.
S>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.

SM>>Для предметных областей было приведено как минимум два примера:
SM>>1. Добавление клиента (T2) для изменяемого документа (T1)
S>Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.
Может быть как минимум две причины:
1. Не возможности открыть ещё одно соединение
2. Спроектированная архитектура приложения

SM>>2. Ведение лога работы пользователя (работа в T1, лог в T2)
S>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?
Глобально — ничему.
Локально — я так и не понял, а чем плохо всё это делать из одного соединения.

Здравствуйте, IB, Вы писали:

IB>Интересны правильные архитектурные решения — стабильные, хорошо масштабируемые и легко сопровождаемые. И я делюсь своим опытом как такие решения получать. Я ни в коем случае никого не заставляю поступать именно так. Я лишь объясняю как делать не следует и почему. Меня можно не слушать, мне вообщем-то все равно, только хамить не надо.

Иван, в этой ветке не надо было обсуждать архитектуру. В ней пытались прояснить вопрос про несколько независимых транзакций в рамках одного подключения. В IB/FB такое есть с самого рождения. У других серверов — это моделируется. MARS, из-за которого все и покатилось, получается вообще ни при чем — примеров, которые можно просто взять и потестить, так и не привели.

КД>>Причин по которым не сериализуют транзакции друг за другом наверное много. Но я не буду тут гадать какие.
IB>То есть, лень задуматься? Или просто не интересно? Тоже забавная позиция, думать лень, но спорить будем до упора.

И знаешь почему? Потому что, то что у меня работает уже пять лет работает у удовлетворяет всем твоим вышеуказанным интересам, в свое время тоже вызывало на форумах кучу противоречивых суждений. От того что "это не удовлетворяет классическим правилам проектирования", до "это просто не заведется на текущем железе. типа очень тяжелое". А потом, один уважаемый архитектор из одной очень крупной IT-компании, был очень неприятно удивлен, когда узнал что его опередили, лет так на восемь. Причем не на Оракле, а на каком-то странном сервере по названии Firebird. Потом, чтобы хоть как-то оправится, этот забавный старикан начал обвинять меня в использовании "файл-серверной" архитектуры, что может вывести из равновесия кого угодно

Про мое отношение к репликации — ты наверное помнишь (август 2005 года)

Про то, где должна работать бизнес логика — у меня тоже есть очень "забавное" виденье.

И все эти вопросы я готов "с пеной у рта" обсуждать. Но не в теме, которая вообще говоря касается специфики компонент доступа. В этой теме, я бы поделился конкретной информацией (вплоть до конкретного кода на плюсах) о том как это реализуется на FB и как это моделируется для MSSQL. И что об этом говорится в спецификации — которой вообще плевать на тип сервера.

КД>>1. Кстати говоря, даже если полностью множество выбрали — блобы и массивы у FB/IB закачиваются отдельными вызовами для которых нужна транзакция (желательно та, в которой получили их дескрипторы).
IB>То есть, это особенность FB? Возвращаясь к началу спора, в чем тогда MS провинился, если ему это нафиг не уперлось?

Да, Иван, здесь в IB/FB тоже пошли немного дальше. И ты не поверишь, в OLEDB это тоже прописано. Причем у IB/FB (как в отчете о навороченной железяки) напротив каждого пункта стоит плюсик. А MSSQL — минусы. Забавно, но это факт (полагаю из за специфики обмена с сервером). Есть и отложенное чтение, нет ограничений на порядок чтения колонок с блобами и нет ограничений на число открытых потоков через которые BLOB-ы грузятся. По умолчанию, ясный пень, компоненты доступа могут грузить все и сразу. Хотя, если опуститься на уровень пониже, ADODB запрашивает значения колонок по отдельности. Поэтому если ты не будешь лезть к Value колонки с BLOB-ом, блоб просто не будет загружен. Мелочь, а приятно.

Вообще говоря компоненты доступа (их интерфейсы), могут как полностью отупить сервер, так и наоборот раскрыть весь его потенциал. Вот за что я люблю OLEDB и сниму шляпу перед его авторами — они не отупляют. Но если взять первоначальный DBExpress, рожденного как минимум после недельного запоя — у меня самые негативные чувства. ADO.NET хоть отчасти и похоже, но реально граммотнее спроектировано.

КД>>В результате, при наличии незавершенной транзакции может появится другая. В отношении MSSQL — и новое подключение, а для IB/FB -
КД>> просто еще одна транзакция.
IB>Байта ради. Конечный разработчик этого не заметит. С точки зрения производительности и ресурсов — тоже разницы никакой. Это просто особенности внутренней реализации. Так какой смысл обвинять MS что он делает по другому?

Её никто не обвиняет. В ветке, грубо говоря, защищали Джима (тоже кстати, считается классиком среди архитекторов), который сказал — "да будет так". Насколько я помню именно Джими придумал и блобы тоже.

КД>>Если этого еще не говорили другие, напомню — что старт и коммит транзакций на FB/IB — это полностью в руках клиентской части. То есть — либо "в руках" компонент доступа, либо "в руках" конечного ПО.
IB>Ну это опять-таки проблемы FB, причем конкретные проблемы. Если MS и другие сервера могут себе позволить без этого обойтись, то это не их вина.

Это не проблемы — это, черт побери, его принципы. Обусловленные тем что в 198-каком-то там году (когда, думаю, они и были сформулированы), мало кто вообще себе представлял что должен из себя представлять сервер БД и как с ним работать. Решили, что управление лучше не размазывать. Добавить всегда успеют, в удалить... Самое что поразительное, если не сравнивать с навороченным OLEDB, интерфейс клиента получился достаточно граммотным. Но по сравнению с OLEDB — отдыхает (что и понятно — процедуры vs объекты), хотя и в состоянии заполнить его изнутри.

Для тебя наверное это дико — но это не значит, что другие не воспринимают это "как само собой разумеющееся". Сейчас прикрутят хранимые процедуры/триггеры на "яве и пр." может Дима Еманов и скажет — "да будут собственные транзакции на уровне сервера".

КД>>2. Просто не в состоянии проконтролировать и гарантировать что во время работы линейного алгоритма какая-та его настраиваемая часть (то есть та, которая может модифицироваться после сдачи приложения в эксплуатацию — скрипты/внешние компоненты) вдруг не решит, что ей край какие-то (служебные?) данные прочитать в собственной независимой транзакции. А может это вообще изначально по-сценарию так надо. Или это очередной студент, который решил что это круто, или ему, допуская "к телу", не объяснили базовых принципов.
IB>Нет никаких проблем вынести настраиваемые части за рамки внутренних транзакций.

Мда... а если эти алгоритмы напрямую завязаны на базу данных? Ну там, читают из неё данные, склеивают, разваливают, анализируют, контролируют. Иван, меня "как архитектора", не волнуют детали — я только придумал как такие "компонентые" алгоримы конструировать. И кстати юзаю для этого технологии того же MS.

А если мне понадобить запретить этим кусочным алгоримам заниматься самодеятельность — я тоже знаю как это сделать. И в спецификациях MS — для этого есть подходящие/похожие конструкции.

КД>>Иногда они возводят в ранг "абсолютной" истины свои идеи, потому что не знают про другие, знают о них "по-наслышке" или просто хотят что-то доказать. Забыв что доказать можно только одно — собственную глупость.
IB>Угу. Наблюдал тут недавно, ужас просто Некоторые оппоненты иногда, ну просто как дети..

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

КД>>Так что, Иван, с кругозором у твоих "оппонентов" все нормально. Полагаю, что со способностью уважать "чужой образ жизни" — тоже.
IB>Незнаю-незнаю. Они заставили меня в этом всерьез засомневаться.

Будь проще, и люди к тебе потянутся.

Здравствуйте, SmlMouse, Вы писали:
S>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции

SM>>>Для предметных областей было приведено как минимум два примера:
SM>>>1. Добавление клиента (T2) для изменяемого документа (T1)
S>>Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.
SM>Может быть как минимум две причины:
SM>1. Не возможности открыть ещё одно соединение
А что мешает?
SM>2. Спроектированная архитектура приложения
ХаХа.

S>>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?
SM>Глобально — ничему.
SM>Локально — я так и не понял, а чем плохо всё это делать из одного соединения.
Напомню, что вопрос был ровно наоборот — "зачем всё запихивать в одно соединение". Поклонники FB уже сотню постингов пытаются отстоять свое право чесать левое ухо правой ногой.
Пока что, на мой взгляд, неубедительно. Важность этой фичи как минимум преувеличена. Как максимум — предлагаемые примеры либо ведут к заведомо ошибочной архитектуре, либо непринужденно делаются на разных соединениях.

Еще раз объясняю: если у вас есть техническая возможность организовать несколько логических соединений поверх одного канала — замечательно. Но зачем заставлять программиста думать об этом — мне непонятно.

Здравствуйте, Sinclair, Вы писали:

S>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции
???

S>>>Здесь T2 никак не связана с T1. Поэтому, вообще говоря, непонятно, зачем акцентироваться на параллельных транзакциях. Открыл соединение — добавил клиента — закрыл соединение.
SM>>Может быть как минимум две причины:
SM>>1. Не возможности открыть ещё одно соединение
S>А что мешает?
Например, если сервер линкуется в приложение (full embeded), то несколько соединений без конкретных плясок открыть нет возможности.

SM>>2. Спроектированная архитектура приложения
S>ХаХа.
Забавный аргумент

S>>>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?
SM>>Глобально — ничему.
SM>>Локально — я так и не понял, а чем плохо всё это делать из одного соединения.
S>Напомню, что вопрос был ровно наоборот — "зачем всё запихивать в одно соединение". Поклонники FB уже сотню постингов пытаются отстоять свое право чесать левое ухо правой ногой.
S>Пока что, на мой взгляд, неубедительно. Важность этой фичи как минимум преувеличена. Как максимум — предлагаемые примеры либо ведут к заведомо ошибочной архитектуре, либо непринужденно делаются на разных соединениях.
Потому что:
1. Может, насоветуете альтернативную СУБД:<br />
* бесплатная;<br />
* <b>параллельные транзакции</b>;

Автор: mmaxx
Дата: 19.09.07

2. Re[6]: <br />
<span class='lineQuote level1'> КДВ&gt; Есть коннект. в его рамках можно одновременно стартовать несколько транзакций.</span><br />
IB: Вот это уже не логично.

Автор: IB
Дата: 19.09.07

S>Еще раз объясняю: если у вас есть техническая возможность организовать несколько логических соединений поверх одного канала — замечательно.
S>Но зачем заставлять программиста думать об этом — мне непонятно.
Не так. Есть техническая возможность это использовать.
Почему это использовать нельзя?

Здравствуйте, Sinclair, Вы писали:

SM>>2. Ведение лога работы пользователя (работа в T1, лог в T2)
S>То же самое. Ведите лог через отдельное соединение. Чему это противоречит?

Да ничему не противоречит, вот только те кто профессионально работает с FB/IB, знают о такой архитектуре как Классик-Сервер. И о последствиях этого отдельного подключения к базе.

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

Кстати говоря — насчет моветона "одного подключения". Уж поверь, при граммотной архитектуре приложения, ну никто не мешает как все время держать подключение, так и создавать его по требованию. В случае OLEDB, например, достаточно работать не с нативе-провайдером, а микрософтовкой надстройкой.

---
Очень надеюсь что сейчас не будет ответа "А! Так это это опять специфика, которая MS даром не впилась". Да это специфика, о которой, повторюсь, знает любой профессионал.

Если тут такие умные — можете подключиться к разработке сервера и продемонстрировать свою техническую подготовку в разработке супера третьей версии FB. Но боюсь статус архитекторов не позволит спуститься на такой уровень. Впрочем, Еманова уже вывернуло наизнанку программирование одно архитектора. И я его, очень хорошо понимаю

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, SmlMouse, Вы писали:
S>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции не пересеклись по данным. Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, SmlMouse, Вы писали:
S>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции

"Чтобы что"??? Чтобы не они не ступили друг другу на йайца?

С точки зрения конечной целостности данных, если они наступят в одном подключении — наступят и в разных.

S>Еще раз объясняю: если у вас есть техническая возможность организовать несколько логических соединений поверх одного канала — замечательно. Но зачем заставлять программиста думать об этом — мне непонятно.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, SmlMouse, Вы писали:
S>>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции не пересеклись по данным.
Вот этого я не понял.
Если можно, поподробней.

S>Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.
Это преимущественно вопрос архитектуры клиентских библиотек.
Для IB/FB/YA обычно вообще открывается одно соединение на всё время жизни приложения, поэтому следить за закрытием соединения нет необходимости.
Так же открытвается пару read-only r-c транзакций для всяких сервисных нужд и фетч-запросов.
Все остальные write транзакции обычно нужны для конкретных операций, вытекающих из бизнес-логики, и там вступают в силу совсем другие принципы.
Всё это я к чему написал: проблема согласования времени жизни транзакции с временем жизни коннекта — это как бы совсем не проблема.
По крайней мере при использовании IB-based с соответсвующей архитектурой доступа она настолько ничтожна, что обращать внимание на неё не стоит.

Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Если тут такие умные — можете подключиться к разработке сервера и продемонстрировать свою техническую подготовку в разработке супера третьей версии FB.
Ну, в свете присутствия линейки MS SQL мне догонять Редмонд лень

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, SmlMouse, Вы писали:
S>>>>Какая разница, сколько здесь коннектов? Тот факт, что это тот же коннект, нигде не используется.
SM>>>Разницы на самом деле никакой. Всё это можно сделать и из двух разных коннектов.
SM>>>Просто я так и не понял, почему плохо всё это делать в одном коннекте двумя разными транзакциями.
S>Ок. Плохо это — потому, что нужно следить за тем, чтобы разные транзакции не пересеклись по данным. Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.

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

В этой ветке, как я понимаю 9 из 10 — архитекторы. Ну как акушер с акушерами поделюсь решением, обеспечивающего синхронность коммита. Берешь интерфейс объекту, управляющего транзакцией. Пишешь реализацию, которая делегирует вызовы своих методов в список "настоящих" транзакций. И все. Никто ничего не забудет. Ну да. Конечно, можно взять готовое решение — MS DTC.

Кстати, говоря, программер в моей душе еще не умер — и если юзаешь IBProvider третьей версии, то можешь дочерние транзакции подцепить к уведомлениям основной транзакции (через ITransactionJoin) и при коммите основной транзакции, автоматически закоммитишь дочерние. Так сказать, халявный DTC. Представляешь какая продуманская технология, эта микрософтовская OLEDB. Я сам ничего не придумывал — взял на вооружение чужое.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Если тут такие умные — можете подключиться к разработке сервера и продемонстрировать свою техническую подготовку в разработке супера третьей версии FB.
S>Ну, в свете присутствия линейки MS SQL мне догонять Редмонд лень

Вот это как раз и есть реальная проблема "архитекторов". Не любят марать руки об реальный код.

Но тем неменее. В Редмонде работают реальные люди, как в прочем и в борланде, и в команде FB. И я, в силу своего характера, очень хорошо понимаю что географическое положение не влияет на мозги. И в связи с этим, в свое время на форуме OSP.RU "послал накуй" Сергея Кузнецова, который я так понимаю гуру российкого общества баз данных. А может его "однофамильца". Прошло восемь с лихом лет — я своего мнения, по этому вопросу, не поменял.

Здравствуйте, SmlMouse, Вы писали:
SM> Если можно, поподробней.
Я только что привел пример того, как две транзакции пересекаются по данным. Такой риск есть, если в коде одного потока перемешаны обращения в разных контекстах транзакций. Делов-то — заселектили в одной, записали в другой. Всё даже будет работать, пока нагрузка не возрастет.
А если работа с транзакциями разведена по разным потокам, то нужно следить за синхронизацией работы с соединением — та самая нудная многопоточность, про которую писал Иван.

S>>Чтобы соединение не закрылось раньше, чем произошел коммит всех транзакций. Ну и так далее.
SM> Это преимущественно вопрос архитектуры клиентских библиотек.
SM> Для IB/FB/YA обычно вообще открывается одно соединение на всё время жизни приложения, поэтому следить за закрытием соединения нет необходимости.
Это плохо масштабируемая архитектура. С точки зрения сервера, эти соединения почти всё время простаивают. Тем не менее, ему нужно держать ресурсы, ассоциированные с каждым подключением. Именно из-за этого изобрели connection pooling.
Удержание соединения придумано не из-за Interbase, а из-за того, что сначала с ним работал только BDE, спроектированный для парадокса. Уже потом пришлось для решения очевидных проблем прикручивать все эти костыли.

SM> Так же открытвается пару read-only r-c транзакций для всяких сервисных нужд и фетч-запросов.
SM> Все остальные write транзакции обычно нужны для конкретных операций, вытекающих из бизнес-логики, и там вступают в силу совсем другие принципы.
SM> Всё это я к чему написал: проблема согласования времени жизни транзакции с временем жизни коннекта — это как бы совсем не проблема.
SM> По крайней мере при использовании IB-based с соответсвующей архитектурой доступа она настолько ничтожна, что обращать внимание на неё не стоит.
Ну то есть детали реализации диктуют архитектуру?
Я про Interbase вообще преисполнен пессимизма. Имею богатый негативный опыт работы с ним. Я в курсе, что с тех пор много воды утекло; тем не менее, осадок остался.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Кстати, говоря, программер в моей душе еще не умер — и если юзаешь IBProvider третьей версии, то можешь дочерние транзакции подцепить к уведомлениям основной транзакции (через ITransactionJoin) и при коммите основной транзакции, автоматически закоммитишь дочерние.
А, так речь идет про вложенные транзакции? Или таки про параллельно-независимые?

Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Но тем неменее. В Редмонде работают реальные люди, как в прочем и в борланде, и в команде FB. И я, в силу своего характера, очень хорошо понимаю что географическое положение не влияет на мозги. И в связи с этим, в свое время на форуме OSP.RU "послал накуй" Сергея Кузнецова, который я так понимаю гуру российкого общества баз данных. А может его "однофамильца". Прошло восемь с лихом лет — я своего мнения, по этому вопросу, не поменял.
Не, ну давайте теперь меряться, кто кого послал и кто кому гуру.
Я вот лет восемь тому назад послал накуй Interbase 5.5 и 6.0 за неотчуждаемые родовые травмы головы, и своего мнения по этому вопросу не поменял. Потому что его писали люди, которые под СУБД понимали что-то другое, чем я. Возможно, с тех пор Interbase вышел из транса и научился хотя бы корректно выполнять простейшие запросы, но я к нему до сих пор отношусь с крайним подозрением. Я уважаю его умение работать во встраиваемом режиме, но в моих приложениях как раз это малосущественно.