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

A>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.

Это значит надо все бизнес-транзакции обрачивать в транзакции БД?

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

A>>Это другая ветка, ты даже сам не знаешь на что отвечаешь. Что и требовалось доказать.
kuj>Не вижу смысла плодить ответы на Ваш бред в разных ветках.

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

A>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
kuj>Кто Вам эту чушь сказал? Еще один пример полной некомпетентности. ликбез: при обрыве связи происходит rollback транзакции.

Так как у нас есть бизнес-транзакции, завершение или откат транзакции БД не обозначают, что данные в согласованном состоянии. И это... перестаём хамить.

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


A>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
kuj>>Кто Вам эту чушь сказал? Еще один пример полной некомпетентности. ликбез: при обрыве связи происходит rollback транзакции.

A>Так как у нас есть бизнес-транзакции, завершение или откат транзакции БД не обозначают, что данные в согласованном состоянии. И это... перестаём хамить.

Да при чем тут вообще бизнес-транзакции? Или у вас бизнесс-транзакции в ХПы запиханы?

Вообщем неудачная попытка съехать с темы.

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

kuj>Да при чем тут вообще бизнес-транзакции? Или у вас бизнесс-транзакции в ХПы запиханы?

Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL.

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


kuj>>Да при чем тут вообще бизнес-транзакции? Или у вас бизнесс-транзакции в ХПы запиханы?

A>Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL.

Чушь.

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

A>>Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL.
kuj>Чушь.

Если не трудно, вырази свою мысль чуть подробнее. Например как бы ты решал эту задачу (бизнес-транзакция CreateUser+CreateSite) с учётом возможных аппаратных сбоев.

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

A>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?
Те которые могут нарушить целостность БД — обязательно. Если нужны долгие бизнес-транзакции — используем оптимистическое версирование и т.п. В общем, у меня это вполне получается.

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

A>>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?
C>Те которые могут нарушить целостность БД — обязательно.

Ну да, а потом мне рассказывают что ХП — зло. А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся

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


A>>>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>>>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>>>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?
C>>Те которые могут нарушить целостность БД — обязательно.

A>Ну да, а потом мне рассказывают что ХП — зло.
Естественно зло. И вам уже 100 раз объяснили почему. Уж очень туго до Вас доходит.

A>А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся
Вы хоть поняли что сказали?

Еще раз для тех, кто в танке: ORM в частности NHibernate дает более богатый инструментарий для управления транзакциями БД.

Бизнес-транзакции же понятие высокоуровневое и во многих случаях абстрактное. Есть, например, BTP — Business Transaction Protocol для организации БТ через Интернет. Какое он по-вашему имеет отношение к техническим транзакциям какой-то конкретной БД? Никакого.

И этот человек еще обвинял меня в непонимании разницы между бизнес-транзакциями и транзакциями БД, когда сам ни того, ни другого не понимает. Смешно.

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

C>>>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>>>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?
Нет. Только те части бизнес-транзакций, которые в случае сбоя могут нарушить целостность данных.

C>>Те которые могут нарушить целостность БД — обязательно.
A>Ну да, а потом мне рассказывают что ХП — зло. А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся
Нет.

К примеру, стандартная задача — несколько web-страниц с формочками. Это представляет из себя одну бизнес-транзакцию, она состоит из нескольких read-only транзакций с базой (показываем формочки) и финальной записи (нажили "OK" на последней форме).

Соответственно, эта вот финальная запись должна _обязательно_ выполнятся в одной транзакции БД. Иначе у нас есть возможность нарушить целостность.

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

A>>Ну да, а потом мне рассказывают что ХП — зло.
kuj>Естественно зло. И вам уже 100 раз объяснили почему. Уж очень туго до Вас доходит.

Лично ты вообще ничего не объяснил. Только поохал.

A>>А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся
kuj>Вы хоть поняли что сказали?

Не хами.

kuj>Еще раз для тех, кто в танке: ORM в частности NHibernate дает более богатый инструментарий для управления транзакциями БД.

Но не обеспечивает устойчивость к аппаратным сбоям.

kuj>Бизнес-транзакции же понятие высокоуровневое и во многих случаях абстрактное. Есть, например, BTP — Business Transaction Protocol для организации БТ через Интернет. Какое он по-вашему имеет отношение к техническим транзакциям какой-то конкретной БД? Никакого.

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

kuj>И этот человек еще обвинял меня в непонимании разницы между бизнес-транзакциями и транзакциями БД, когда сам ни того, ни другого не понимает. Смешно.

Смешно, что ты не даёшь ответов на вопросы только декларируя неправоту оппонента, но не объясняя сути неправоты и не приводя правильного решения, а потом надеешься на понимание.
Я всё ещё жду ответа тут http://www.rsdn.ru/Forum/Message.aspx?mid=2674656&amp;only=1

Автор: adontz
Дата: 29.09.07

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

C>К примеру, стандартная задача — несколько web-страниц с формочками. Это представляет из себя одну бизнес-транзакцию, она состоит из нескольких read-only транзакций с базой (показываем формочки) и финальной записи (нажили "OK" на последней форме).

Read-only не интересно.

C>Соответственно, эта вот финальная запись должна _обязательно_ выполнятся в одной транзакции БД. Иначе у нас есть возможность нарушить целостность.

Есть случаи гораздо сложнее. Вот реальный пример.
Некоторая околоавтомобильная система. Пользователи двух типов: клиенты — владельцы автомобилей и обслуживающий первонал. Табличка Users на всех одна (достаточно много общих действий) со столбцом Kind. У клиентов объязательно есть автомобиль. Может быть не один, но один точно. У обслуживающего персонала — нет.
Соответственно есть некоторое окно по редактированию списка автомобилей доступное только для пользователя-клиента. При его написании подразумевалось, что множество автомобилей не пусто (по условиям ТЗ). Скажем, это выражается в том, что всегда вызывается _carListView.SetSelection(0) для выделения первого автомобиля в списке.
Сценрий. Добавляем нового клиента вводя его данные и данные его первого автомобиля. Вызывается CreateUser, соединение с БД рвётся, try/catch ловит какой-то бред.
Восстанавливаем систему. Пользователь есть в списке, но окно редактирования списка автомобилей при попытке открытия вылетает с исключением. Удалить пользователя нельзя (условие ТЗ).
Конечно решения есть. По уму на стороне DAL должен был вестись лог транзакций и после восстановления соединения пользователь должен был быть удалён. Ну или не лог транзакций но какой-то способ отката. Кто это будет писать в таком виде? Конечно, сделают ХП для CreateUserAndFirstCar, CreateNextCar с большим количеством общего кода потому что так намного проще.
Может быть и менее экстремально, но не лучше — после CreateUser кто-то просто считал список пользователей. Транзакции это ведь не только возможность отката, но и уровни изоляции. Да, проблема решается Refresh'ем, только это не решение вовсе. Так что корректные бизнес-транзакции не на уровне БД это редкстный геморрой на самом деле.

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

kuj>>Еще раз для тех, кто в танке: ORM в частности NHibernate дает более богатый инструментарий для управления транзакциями БД.

A>Но не обеспечивает устойчивость к аппаратным сбоям.

Обеспечивает ровно в той же мере, что и хранимые процедуры. Хватит уже чушь молоть.

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

A>>Но не обеспечивает устойчивость к аппаратным сбоям.
kuj>Обеспечивает ровно в той же мере, что и хранимые процедуры. Хватит уже чушь молоть.

Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни.

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

C>>Соответственно, эта вот финальная запись должна _обязательно_ выполнятся в одной транзакции БД. Иначе у нас есть возможность нарушить целостность.

A>Есть случаи гораздо сложнее. Вот реальный пример.
A>Некоторая околоавтомобильная система. Пользователи двух типов: клиенты — владельцы автомобилей и обслуживающий первонал. Табличка Users на всех одна (достаточно много общих действий) со столбцом Kind. У клиентов объязательно есть автомобиль. Может быть не один, но один точно. У обслуживающего персонала — нет.
A>Соответственно есть некоторое окно по редактированию списка автомобилей доступное только для пользователя-клиента. При его написании подразумевалось, что множество автомобилей не пусто (по условиям ТЗ). Скажем, это выражается в том, что всегда вызывается _carListView.SetSelection(0) для выделения первого автомобиля в списке.
A>Сценрий. Добавляем нового клиента вводя его данные и данные его первого автомобиля. Вызывается CreateUser, соединение с БД рвётся, try/catch ловит какой-то бред.
A>Восстанавливаем систему. Пользователь есть в списке, но окно редактирования списка автомобилей при попытке открытия вылетает с исключением. Удалить пользователя нельзя (условие ТЗ).
A>Конечно решения есть. По уму на стороне DAL должен был вестись лог транзакций и после восстановления соединения пользователь должен был быть удалён. Ну или не лог транзакций но какой-то способ отката. Кто это будет писать в таком виде? Конечно, сделают ХП для CreateUserAndFirstCar, CreateNextCar с большим количеством общего кода потому что так намного проще.
A>Может быть и менее экстремально, но не лучше — после CreateUser кто-то просто считал список пользователей. Транзакции это ведь не только возможность отката, но и уровни изоляции. Да, проблема решается Refresh'ем, только это не решение вовсе. Так что корректные бизнес-транзакции не на уровне БД это редкстный геморрой на самом деле.

Еще раз: есть системы, в которых ЕСТЬ бизнес-транзакции, но НЕТ БД.

Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.
Более того, для такого простого сценария нет никакой необходимости держать транзакцию открытой все это время:
Создается объект User, в коллекцию Cars добавляется автомобиль, а по окончании делается пакетный Flush в БД внутри транзакции (с гораздо меньшим временем жизни). Все.

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

A>>>Но не обеспечивает устойчивость к аппаратным сбоям.
kuj>>Обеспечивает ровно в той же мере, что и хранимые процедуры. Хватит уже чушь молоть.

A>Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни.

Что опровергнуть? Что NHibernate уступает ХП в плане управления транзакциями БД? Вам разные люди твердят, что ничем не уступает, и напротив предоставляет дополнительный инструментарий, а Вы продолжаете упорствовать?
Читайте документацию по NHibernate (Hibernate), ADO.NET (JDBC) пока не поймете этого. Заниматься восполнением пробелов в вашем образовании я не собираюсь.

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

A>>Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни.
kuj>Что опровергнуть? Что NHibernate уступает ХП в плане управления транзакциями БД? Вам разные люди твердят, что ничем не уступает, и напротив предоставляет дополнительный инструментарий, а Вы продолжаете упорствовать?
kuj>Читайте документацию по NHibernate (Hibernate), ADO.NET (JDBC) пока не поймете этого. Заниматься восполнением пробелов в вашем образовании я не собираюсь.

Опять нет ответа, одно хамство. Это уже закономерность какая-то...

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

kuj>Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.

Hibernate это уровень DAL и поддерживать бизнес транзакции он не в состоянии. То что ты указал это не решение средствами Hibernate, потому что ты открываешь транзакцию БД. Если у тебя бизнес-транзакция CreateUser+CreateCar+SendSmsToAdmin, то Hibernate тут ничем не поможет, потому что бизнес-транзакции вне компетенции Hibernate.

kuj>Более того, для такого простого сценария нет никакой необходимости держать транзакцию открытой все это время:
kuj>Создается объект User, в коллекцию Cars добавляется автомобиль, а по окончании делается пакетный Flush в БД внутри транзакции (с гораздо меньшим временем жизни). Все.

Время жизни не имеет абсолютно никакого принципиального значения в данном случае. Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций. Либо эта задача решается в лоб, что приводит к написания большого объёма достаточно сложного кода, либо сваливается на БД в которых транзакции уже есть.

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

C>>К примеру, стандартная задача — несколько web-страниц с формочками. Это представляет из себя одну бизнес-транзакцию, она состоит из нескольких read-only транзакций с базой (показываем формочки) и финальной записи (нажили "OK" на последней форме).
A>Read-only не интересно.
Можно read/write, но там уже несколько вариантов.

A>Соответственно есть некоторое окно по редактированию списка автомобилей доступное только для пользователя-клиента. При его написании подразумевалось, что множество автомобилей не пусто (по условиям ТЗ). Скажем, это выражается в том, что всегда вызывается _carListView.SetSelection(0) для выделения первого автомобиля в списке.
A>Сценрий. Добавляем нового клиента вводя его данные и данные его первого автомобиля. Вызывается CreateUser, соединение с БД рвётся, try/catch ловит какой-то бред.
A>Восстанавливаем систему. Пользователь есть в списке, но окно редактирования списка автомобилей при попытке открытия вылетает с исключением. Удалить пользователя нельзя (условие ТЗ).
Решается не просто, а очень просто. При регистрации пользователя данные накапливаются в сессии, а добавление первого автомобиля — часть регистрации.

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

Кстати, для именно таких сценариев в Java сделали библиотеку под названием "Seam" (которая, естественно, может использовать Hibernate), там оно всё красиво инкапсюлируется в виде "conversation"'ов.

A>Конечно решения есть. По уму на стороне DAL должен был вестись лог транзакций и после восстановления соединения пользователь должен был быть удалён. Ну или не лог транзакций но какой-то способ отката. Кто это будет писать в таком виде? Конечно, сделают ХП для CreateUserAndFirstCar, CreateNextCar с большим количеством общего кода потому что так намного проще.
Ты предлагаешь черезчур навороченое и сложное решение. Можно все делать намного проще и надежнее.

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

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

вот об том и речь., что ты не в состоянии дёшево отганизовать транзакции вне БД и делаешь две операции CreateUserWithCar и CreateCar имеющие много общего кода (копи-паст, если по простому).