kuj>>Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.
A>Hibernate это уровень DAL и поддерживать бизнес транзакции он не в состоянии. То что ты указал это не решение средствами Hibernate, потому что ты открываешь транзакцию БД. Если у тебя бизнес-транзакция CreateUser+CreateCar+SendSmsToAdmin, то Hibernate тут ничем не поможет, потому что бизнес-транзакции вне компетенции Hibernate.
CreateUser+CreateCar+CommitTransaction+SendSmsToAdmin. CommitTransaction все накопленные в сессии данные сбрасывает внутри одной транзакции в базу.
Вы все еще не понимаете?
kuj>>Более того, для такого простого сценария нет никакой необходимости держать транзакцию открытой все это время: kuj>>Создается объект User, в коллекцию Cars добавляется автомобиль, а по окончании делается пакетный Flush в БД внутри транзакции (с гораздо меньшим временем жизни). Все.
A>Время жизни не имеет абсолютно никакого принципиального значения в данном случае. A>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций.
В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете? A>Либо эта задача решается в лоб, что приводит к написания большого объёма достаточно сложного кода, либо сваливается на БД в которых транзакции уже есть.
(вздыхая) почитайте чтоли на досуге про BTP и как бизнес-транзакции могут существовать без помощи транзакций БД...
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[40]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>CreateUser+CreateCar+CommitTransaction+SendSmsToAdmin. CommitTransaction все накопленные в сессии данные сбрасывает внутри одной транзакции в базу. kuj>Вы все еще не понимаете?
Это ты не понимаешь, что если SMS не отослался, то создание юзера надо откатить.
CreateUser+CreateCar+SendSmsToAdmin+CommitTransaction
БД не пуп земли.
A>>Время жизни не имеет абсолютно никакого принципиального значения в данном случае. A>>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций. kuj>В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете?
В задачи БД входят транзакции которые используют для транзакционирования логики не имеющей к БД прямого отношения. Это факт, ты сам только что так предлагал.
A>>Либо эта задача решается в лоб, что приводит к написания большого объёма достаточно сложного кода, либо сваливается на БД в которых транзакции уже есть. kuj>(вздыхая) почитайте чтоли на досуге про BTP и как бизнес-транзакции могут существовать без помощи транзакций БД...
А я и не отрицаю что могут. просто это не дёшео. А ты кстати сам давно читал? А то весь дня два как про бизнес-транзакции знаешь. И когда только успел? Молодец!
C>>В конце регистрации — коммит всей накопленой информации в базу в одной транзакции. Тогда у нас гарантировано система всегда будет в целостном состоянии — если у нас во время коммита в сервер приложений попадет метеорит, то транзакция в базе данных потом спокойно откатится по таймауту. С точки зрения остальных клиентов все изменения тоже атомарны.
A>вот об том и речь., что ты не в состоянии дёшево отганизовать транзакции вне БД и делаешь две операции CreateUserWithCar и CreateCar имеющие много общего кода (копи-паст, если по простому).
Я Вам уже говорил. И еще раз повторю. Ликбез: все транзакции БД выполняются ТОЛЬКО в БД. Понятие бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД с т.з. бизнес-логики.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[41]: Оформление работы с БД в корпоративных приложениях -
A>>>Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни. kuj>>Что опровергнуть? Что NHibernate уступает ХП в плане управления транзакциями БД? Вам разные люди твердят, что ничем не уступает, и напротив предоставляет дополнительный инструментарий, а Вы продолжаете упорствовать? kuj>>Читайте документацию по NHibernate (Hibernate), ADO.NET (JDBC) пока не поймете этого. Заниматься восполнением пробелов в вашем образовании я не собираюсь.
A>Опять нет ответа, одно хамство. Это уже закономерность какая-то...
Вам уже сто раз ответили при чем совершенно разные люди. Разуйте глаза и закройте рот.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[40]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>Я Вам уже говорил. И еще раз повторю. Ликбез: все транзакции БД выполняются ТОЛЬКО в БД. Понятие бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД с т.з. бизнес-логики.
Вот именно. Только организовать эти транзакции вне БД тебе слишком сложно и проще засунуть в БД всё что туда вообще можно засунуть.
Ты сам сказал
Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.
Теперь давай тоже самое, но без "открыв транзакцию БД в начале", потому что, как ты правильно заметил, "бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД".
Здравствуйте, adontz, Вы писали:
kuj>>CreateUser+CreateCar+CommitTransaction+SendSmsToAdmin. CommitTransaction все накопленные в сессии данные сбрасывает внутри одной транзакции в базу. kuj>>Вы все еще не понимаете?
A>Это ты не понимаешь, что если SMS не отослался, то создание юзера надо откатить. A>CreateUser+CreateCar+SendSmsToAdmin+CommitTransaction
A>БД не пуп земли.
В таком случае Вам никто и ни что не поможет, т.к. нельзя сделать rollback уже отправленной SMS. Единственное, что приходит на ум добавить это добавить информацию по SMS в специальную таблицу в БД, с которой работает отдельный сервис в режиме чтения, рассылая эти SMS.
A>>>Время жизни не имеет абсолютно никакого принципиального значения в данном случае. A>>>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций.
------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ kuj>>В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете? A>В задачи БД входят транзакции которые используют для транзакционирования логики не имеющей к БД прямого отношения. Это факт, ты сам только что так предлагал.
---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Мда... клиника. Вы сами себе противоречите. Определитесь уж: входит или не входит. А заодно разберитесь с понятием бизнес-транзакция и поднапрягите извилину и ответьте на вопрос: должен ли DAL знать что-то о бизнес-логике или не должен.
Намек: транзакции СУБД != бизнес-транзакции. Это понятия совершенно разные и их даже сравнивать нельзя.
A>>>Либо эта задача решается в лоб, что приводит к написания большого объёма достаточно сложного кода, либо сваливается на БД в которых транзакции уже есть. kuj>>(вздыхая) почитайте чтоли на досуге про BTP и как бизнес-транзакции могут существовать без помощи транзакций БД...
A>А я и не отрицаю что могут. просто это не дёшео. А ты кстати сам давно читал? А то весь дня два как про бизнес-транзакции знаешь. И когда только успел? Молодец!
Н-да, смешную вы там травку курите. Поделитесь?
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[41]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
kuj>>Я Вам уже говорил. И еще раз повторю. Ликбез: все транзакции БД выполняются ТОЛЬКО в БД. Понятие бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД с т.з. бизнес-логики.
A>Вот именно. Только организовать эти транзакции вне БД тебе слишком сложно и проще засунуть в БД всё что туда вообще можно засунуть. A>Ты сам сказал A>
A>Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.
A>Теперь давай тоже самое, но без "открыв транзакцию БД в начале", потому что, как ты правильно заметил, "бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД".
Речь о транзакциях С У Б Д. Читаем по буквам медленно и вслух, и повторяем до просветления.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[42]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>В таком случае Вам никто и ни что не поможет, т.к. нельзя сделать rollback уже отправленной SMS. Единственное, что приходит на ум добавить это добавить информацию по SMS в специальную таблицу в БД, с которой работает отдельный сервис в режиме чтения, рассылая эти SMS.
Речь о другом. Если мне не удалось отослать SMS, то надо откатить создание пользователя. Понятно, что SMS это просто пример out-of-database action.
A>>>>Время жизни не имеет абсолютно никакого принципиального значения в данном случае. A>>>>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций. kuj>------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ kuj>>>В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете? A>>В задачи БД входят транзакции которые используют для транзакционирования логики не имеющей к БД прямого отношения. Это факт, ты сам только что так предлагал. kuj>---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
kuj>Мда... клиника. Вы сами себе противоречите. Определитесь уж: входит или не входит. А заодно разберитесь с понятием бизнес-транзакция и поднапрягите извилину и ответьте на вопрос: должен ли DAL знать что-то о бизнес-логике или не должен.
Не хами.
kuj>Намек: транзакции СУБД != бизнес-транзакции. Это понятия совершенно разные и их даже сравнивать нельзя.
Я с этим согласен, но ты потом приводишь решения, которые противоречат твоим же словам. Решение основывающиеся именно на транзакциях БД.
Кстати ты почему-то всё время акцентируешь на возможности откатить. В то же время уровень изоляции не менее важен. Вот пример задачи на котрой это отчётливее проявляется.
Есть табличка Users. После добавления туда пользователя с заданным логином (добавляем для резервации логина, например) распечатывается контракт. После подписывания контракта лист сканируется и загружается в БД. Теперь, внимание, условие: пользователи, не подписавшие контракт, не должны светится в списке пользователей нигде. Подобная бизнес-транзакция может занимать минут 30, а то и пару суток. Решать эту задачу методом "открыв транзакцию БД в начале" не выйдет.
Здравствуйте, adontz, Вы писали:
kuj>>В таком случае Вам никто и ни что не поможет, т.к. нельзя сделать rollback уже отправленной SMS. Единственное, что приходит на ум добавить это добавить информацию по SMS в специальную таблицу в БД, с которой работает отдельный сервис в режиме чтения, рассылая эти SMS.
A>Речь о другом. Если мне не удалось отослать SMS, то надо откатить создание пользователя. Понятно, что SMS это просто пример out-of-database action.
В таком случае (когда Вам НЕ надо откатывать SendSMS) как раз все очень просто — коммит делается после SendSMS в том случае, если она вернула true (или еще как-то уведомила).
kuj>>Намек: транзакции СУБД != бизнес-транзакции. Это понятия совершенно разные и их даже сравнивать нельзя.
A>Я с этим согласен, но ты потом приводишь решения, которые противоречат твоим же словам. Решение основывающиеся именно на транзакциях БД.
Еще раз повторяю: бизнес-транзакция понятие высокоуровневое и физически в программе их можно оформлятьразными способами — транзакции БД это лишь один из способов. С этим способом ORM справляются как минимум не хуже ХП, а скорее даже лучше благодаря более высокоуровневому инструментарию (как-то структурированная обработка исключений или уже упомянутый механизм автоматической оптимистичной блокировки).
A>Кстати ты почему-то всё время акцентируешь на возможности откатить. В то же время уровень изоляции не менее важен. Вот пример задачи на котрой это отчётливее проявляется. A>Есть табличка Users. После добавления туда пользователя с заданным логином (добавляем для резервации логина, например) распечатывается контракт. После подписывания контракта лист сканируется и загружается в БД. Теперь, внимание, условие: пользователи, не подписавшие контракт, не должны светится в списке пользователей нигде. Подобная бизнес-транзакция может занимать минут 30, а то и пару суток. Решать эту задачу методом "открыв транзакцию БД в начале" не выйдет.
Как же до вас туго доходит... А ведь про этот механизм в Hibernate уже даааааавно Вам говорили. Чем Вы слушали?
Здравствуйте, kuj, Вы писали:
kuj>В таком случае (когда Вам НЕ надо откатывать SendSMS) как раз все очень просто — коммит делается после SendSMS в том случае, если она вернула true (или еще как-то уведомила).
Всё не так просто, потому что ты забываешь об изоляции транзакции. Пока не пришло подтверждение доставки SMS, недавно соданные User и Car не должны где-либо фигурировать.
kuj>Еще раз повторяю: бизнес-транзакция понятие высокоуровневое и физически в программе их можно оформлятьразными способами — транзакции БД это лишь один из способов.
Здравствуйте, adontz, Вы писали:
kuj>>В таком случае (когда Вам НЕ надо откатывать SendSMS) как раз все очень просто — коммит делается после SendSMS в том случае, если она вернула true (или еще как-то уведомила). A>Всё не так просто, потому что ты забываешь об изоляции транзакции. Пока не пришло подтверждение доставки SMS, недавно соданные User и Car не должны где-либо фигурировать.
Я ничего не забываю. Где они по-вашему будут фигурировать, если мы еще не выполняли flush сессии в БД.
kuj>>Еще раз повторяю: бизнес-транзакция понятие высокоуровневое и физически в программе их можно оформлятьразными способами — транзакции БД это лишь один из способов.
A>Да, но других ты не привёл.
Привел. Читайте внимательнее.
kuj>>http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-basics-apptx kuj>>Читаем до просветления и завязываем этот спор на ровном месте.
A>Там только try/catch решения. Они не предоставляют изоляции и не защищают от аппаратных сбоев.
Сдаюсь... это клиника. Вы даже не удосуживаетесь почитать, а сразу начинаете какую-то ахинею нести. Клиника.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[45]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
kuj>>Логика в теме топика.
A>То есть по существу вопроса тебе ответить нечего, так и запишем.
Я уже ответил по теме топика при чем в нескольких разных ветках. Если Вы не можете открыть гугл и найти информацию по BTP, то я Вам ничем помочь не могу. Клиника.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[46]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>Я ничего не забываю. Где они по-вашему будут фигурировать, если мы еще не выполняли flush сессии в БД.
ОК пришло подтверждение и тут же вырубилась сеть. Получается SMS есть, а юзера нет. Как ни крути, а целостность ты не обеспечишь.
A>>Да, но других ты не привёл. kuj>Привел. Читайте внимательнее.
Дай ссылку.
A>>Там только try/catch решения. Они не предоставляют изоляции и не защищают от аппаратных сбоев. kuj>Сдаюсь... это клиника. Вы даже не удосуживаетесь почитать, а сразу начинаете какую-то ахинею нести. Клиника.
Прочитал и не нашёл. Если это там есть, то процитируй. Не будь голословным и не хами.
Здравствуйте, kuj, Вы писали:
kuj>Я уже ответил по теме топика при чем в нескольких разных ветках. Если Вы не можете открыть гугл и найти информацию по BTP, то я Вам ничем помочь не могу. Клиника.
Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?
kuj>>Я уже ответил по теме топика при чем в нескольких разных ветках. Если Вы не можете открыть гугл и найти информацию по BTP, то я Вам ничем помочь не могу. Клиника.
A>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?
То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[47]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
kuj>>Я ничего не забываю. Где они по-вашему будут фигурировать, если мы еще не выполняли flush сессии в БД.
A>ОК пришло подтверждение и тут же вырубилась сеть. Получается SMS есть, а юзера нет. Как ни крути, а целостность ты не обеспечишь.
Н-дааа..... Может Вы бот? Такой непроходимой тупости я еще не встречал... — про SMS я уже говорил и давал пример решения этой проблемы пару сообщений тому назад.
