Здравствуйте, kuj, Вы писали:
A>>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь? kuj>То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....
То есть мне интересно можешь ли ты написать в сообщении что-либо кроме оскорбления оппонента. Например, развёрнутый ответ на поставленный вопросы, а не ссылки на многокилломентровые статьи где якобы есть ответы, хотя их там совсем нет. Даже процитировать нужные отрывки статей на которые ссылаешься, ты не в состоянии.
Гугл такая штука, в нём можно найти всё что угодно. Например я могу в гугле найти стайтов сто одобряющих фашизм. Это же не значит, что фашизм хорошо, не так ли? Аналогично и тут, то что в гугле есть так или иная информация об обработке бизнес-транзакций вовсе не означает что информация верная. Гугл — поисковая система, а не энциклопедия и за корректностью информации никак не следит. Ссылаться в гугл можно когда тебя спрашивают "чему равно число пи?" или "как называется функция открытия файла?". В данном случае ссылка на гугл неадекватна.
Здравствуйте, adontz, Вы писали:
A>>>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь? kuj>>То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....
A>То есть мне интересно можешь ли ты написать в сообщении что-либо кроме оскорбления оппонента. Например, развёрнутый ответ на поставленный вопросы, а не ссылки на многокилломентровые статьи где якобы есть ответы, хотя их там совсем нет. Даже процитировать нужные отрывки статей на которые ссылаешься, ты не в состоянии. A>Гугл такая штука, в нём можно найти всё что угодно. Например я могу в гугле найти стайтов сто одобряющих фашизм. Это же не значит, что фашизм хорошо, не так ли? Аналогично и тут, то что в гугле есть так или иная информация об обработке бизнес-транзакций вовсе не означает что информация верная. Гугл — поисковая система, а не энциклопедия и за корректностью информации никак не следит. Ссылаться в гугл можно когда тебя спрашивают "чему равно число пи?" или "как называется функция открытия файла?". В данном случае ссылка на гугл неадекватна.
Я понял. Вы бот. Флейм-бот. Нормальный человек в здравом уме такой ахинеи нести не может. Я прекращаю этот спор в одностороннем порядке.
Горбатого могила выправит.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[48]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
A>>ОК пришло подтверждение и тут же вырубилась сеть. Получается SMS есть, а юзера нет. Как ни крути, а целостность ты не обеспечишь. kuj>Н-дааа..... Может Вы бот? Такой непроходимой тупости я еще не встречал... — про SMS я уже говорил и давал пример решения этой проблемы пару сообщений тому назад.
Не хами.
Вот хронология:
1. Запрос на создание пользователя.
(сбой в данный период не приводит к негативным последствиям)
2. Сохранение запроса
(сбой в данный период не приводит к негативным последствиям)
3. Запрос на создание машины
(сбой в данный период не приводит к негативным последствиям)
4. Сохранение запроса
(сбой в данный период не приводит к негативным последствиям)
5. Отсылка SMS
(сбой в данный период приводит к откату)
6. Получение подтверждения доставки SMS
(сбой в данный период приводит к несогласованному состоянию БД. SMS доставлен, но данные в БД не записаны)
7. Запись ранее сохранённых запросов.
Здравствуйте, kuj, Вы писали:
kuj>Я понял. Вы бот. Флейм-бот. Нормальный человек в здравом уме такой ахинеи нести не может. Я прекращаю этот спор в одностороннем порядке. kuj>Горбатого могила выправит.
Слив защитан. по чуществу тебе сказать нечего и ты решил гордо удалиться. Не выйдет. Ты доказал исключительно свою неспособность ответить на элементарные практические вопросы.
Здравствуйте, adontz, Вы писали:
C>>В конце регистрации — коммит всей накопленой информации в базу в одной транзакции. Тогда у нас гарантировано система всегда будет в целостном состоянии — если у нас во время коммита в сервер приложений попадет метеорит, то транзакция в базе данных потом спокойно откатится по таймауту. С точки зрения остальных клиентов все изменения тоже атомарны. A>вот об том и речь., что ты не в состоянии дёшево отганизовать транзакции вне БД и делаешь две операции CreateUserWithCar и CreateCar имеющие много общего кода (копи-паст, если по простому).
Слушай, ты читаешь что тебе пишут вообще? Транзакции вне БД мне нафиг организовывать не нужно — в процессе регистрации в базу данных ничего не пишется.
Единственный момент, когда идет запись — это при завершении регистрации, когда у нас уже есть данные пользователя и данные хотя бы одного автомобиля. В виде псевдокода это можно предствить так:
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kuj, Вы писали:
A>>>Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL. kuj>>Чушь.
A>Если не трудно, вырази свою мысль чуть подробнее. Например как бы ты решал эту задачу (бизнес-транзакция CreateUser+CreateSite) с учётом возможных аппаратных сбоев.
Вам уже пора сделать тему adontz vs kuj , а то зафлудили всю ветку, читать уже невозможно.
Re[38]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Cyberax, Вы писали:
C>Слушай, ты читаешь что тебе пишут вообще? Транзакции вне БД мне нафиг организовывать не нужно — в процессе регистрации в базу данных ничего не пишется. C>Теперь понял?
Сам ты не читаешь Я уже сказал, что этот примитивный случай не интересен, поскольку теряется общность поставновки задачи. У тебя всё в БД, поэтому ты можешь обойтись транзакциями уровня БД. В задаче с отсылкой SMS это не так.
Здравствуйте, adontz, Вы писали:
C>>Слушай, ты читаешь что тебе пишут вообще? Транзакции вне БД мне нафиг организовывать не нужно — в процессе регистрации в базу данных ничего не пишется. C>>Теперь понял? A>Сам ты не читаешь Я уже сказал, что этот примитивный случай не интересен, поскольку теряется общность поставновки задачи. У тебя всё в БД, поэтому ты можешь обойтись транзакциями уровня БД. В задаче с отсылкой SMS это не так.
А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются.
Например, для обеспечения бизнес-правила "у пользователя всегда должна быть машина" можно сделать два типа пользователей: prospect и active (в простейшем случае, добавив флаг 'registration_completed' в табличку пользователя). Далее дизайним приложение так, чтобы для незавершенных пользователей были доступны только формы редактирования его машин. В качестве дополнительной проверки — вешаем check/trigger, проверяющий инвариант "registration_completed xor empty(user.cars)".
В частности, если мне нужно использовать два разных транзакционных ресурса — то я буду использовать распределенные транзакции (XA-транзакции). Причем в XA-транзакции можно добавить один не-XA-ресурс без нарушения гарантий (он делает решающий коммит в конце фазы PREPARE). В твоем случае, скорее всего, таким ресурсом будет посылатель SMS.
Sapienti sat!
Re[49]: Оформление работы с БД в корпоративных приложениях -
Как бы это сделал я.
A>Вот хронология: --- Начинаем XA-транзакцию --- A>1. Запрос на создание пользователя. A>(сбой в данный период не приводит к негативным последствиям) A>2. Сохранение запроса A>(сбой в данный период не приводит к негативным последствиям) A>3. Запрос на создание машины A>(сбой в данный период не приводит к негативным последствиям) A>4. Сохранение запроса A>(сбой в данный период не приводит к негативным последствиям)
4.5 Добавляем SMS-сообщение в очередь сообщений. --- Коммитим XA-транзакцию. Выполняется фаза PREPARE для базы данных, в случае ошибки откатываемся ---
Выполняется В САМОМ КОНЦЕ фазы PREPARE: A>5. Отсылка SMS A>(сбой в данный период приводит к откату) A>6. Получение подтверждения доставки SMS A>(сбой в данный период приводит к несогласованному состоянию БД. SMS доставлен, но данные в БД не записаны)
Сбой в посылку SMS в данный момент приведет к откату XA-транзакции (база данных еще находится в стадии PREPARE).
При успешной посылке SMS — окончательно фиксируем изменения в базе данных. Ошибок на данном этапе не должно быть.
Sapienti sat!
Re[42]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Cyberax, Вы писали:
C>А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются.
Правильно. Об этом я и говорил. Транзакции в БД такие хорошие, что люди всеми правдами и неправдами пытаются использовать именно их, а не писать свои.
Однако этот путьн е без проблем. Во-первых, хотя для большинства приложений это и работает, всё же бывают ситуации когда действие ну никак в БД не впихивается. во-вторых, транзакции это ещё и уровень изоляции. Не зная потрохов SQL запросов можно запросто словить дедлок указав изначально слишком низкий уровень изоляции. Указав слишком высокий получишь starvation. вобщем свои проблемы, помимо чисто идеологических, у этого подхода тоже есть.
Здравствуйте, adontz, Вы писали:
C>>Здравствуйте, adontz, Вы писали: C>>Как бы это сделал я. A>Что такое у тебя XA-транзакция?
Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit
Sapienti sat!
Re[43]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
C>>А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются. A>Правильно. Об этом я и говорил. Транзакции в БД такие хорошие, что люди всеми правдами и неправдами пытаются использовать именно их, а не писать свои.
Именно.
A>Однако этот путьн е без проблем. Во-первых, хотя для большинства приложений это и работает, всё же бывают ситуации когда действие ну никак в БД не впихивается.
Мне пока не попадались. Хотя в некоторых случаях действительно приходилось делать приседания.
Хотя, в принципе, и для таких случаев есть всякие BPMы (Business Process Manager'ы) с поддержкой компенсирующих транзакций.
A>во-вторых, транзакции это ещё и уровень изоляции. Не зная потрохов SQL запросов можно запросто словить дедлок указав изначально слишком низкий уровень изоляции. Указав слишком высокий получишь starvation. вобщем свои проблемы, помимо чисто идеологических, у этого подхода тоже есть.
У меня ни разу еще не появлялось надобности в изоляции больше READ COMMITED. А дедлоки очень эффективно обходятся с помощью оптимистического версирования (поэтому оно мне так и нравится).
Sapienti sat!
Re[52]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Cyberax, Вы писали:
C>>>Как бы это сделал я. A>>Что такое у тебя XA-транзакция? C>Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit
Оно конечно здорово, но вроде кластерная штукенция. То есть, скажем, на SQL Server Express (Standard) этого нет и не будет если я правильно понял что это и зачем.
Здравствуйте, adontz, Вы писали:
A>>>Что такое у тебя XA-транзакция? C>>Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit A>Оно конечно здорово, но вроде кластерная штукенция. То есть, скажем, на SQL Server Express (Standard) этого нет и не будет если я правильно понял что это и зачем.
Нет, тут слово "распределенная" значит, что в транзакции участвуют несколько источников (не обязательно распределенных). В Windows в качестве координатора обычно используется MS DTC, который вроде даже в SQL SE поддерживается.
Sapienti sat!
Re[5]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, nicolas1, Вы писали:
N>>Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.
IT>Зачем ORM для C++? Добрался до буфера резалтсета, преобразовал его к нужной структуре и готово.
Подробнее можно? Т.е. sql запрос к БД, для отновительной простоты, можно оформить его в виде паттерна "active record" для удобства, и разбираем резалт?
Для операций вставки, select, редактирования и удаление все тривиально, но как решается вопрос наследования, отношение one-to-many, many-to-many. Наверно, как раз для этого ORM и существует? Интересует именно объектный доступ к реляционной БД.
Как на практике решается вопрос объектного доступа к реляционной БД в с++: пишется что-то свое, просто мапить объекты на файлы, используется DAL-подход (active record) или что-то еще. Конкретно в случае когда надо, embedded бд, типа sqlite, записей до 500000, наследование, отношения one-to-many, many-to-many (связи между объектами).
Re[36]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Cyberax, Вы писали: S>>Далее, в стоимость коммита начинает входить повторное чтение всех прочитанных в транзакции данных. C>Нет, стандартный прием для версирования: "UPDATE ... SET ... WHERE id=? AND version=?". Если этот оператор вернет 0 (ни одного ряда не обновлено) — то значит у нас оптимистическая ошибка. Можно это сделать и batch'ем для нескольких обновлений.
Эта реализация оптимистической блокировки примерно соответствует уровню read committed. К сожалению, если требуется хотя бы repeatable read, стоимость оптимизма становится значительно выше и такой наивный подход работать не будет.
C>Обычно для сервисов нужно минимизировать длину. Кроме того, тут у нас затраты на память будут на стороне клиента, а не сервера. Так что если он решит похулиганить — то ССЗБ.
Да ну? Не может такого быть. Затраты будут ровно на стороне сервера, т.к. ему нужно накапливать изменения, пока с клиента не придет коммит. Клиент может позволить себе забыть о произведенных действиях сразу после того, как он обратился к серверу.
C>Так пусть себе DDoSит себя — отъест свои соединия и отвалится. На остальных клиентов влиять не будет.
Вопрос интересный.
C>Так ее надо один раз сделать — и она будет решать. Мы вот себе сделали такую неплохую инфраструктуру, в которой есть фичи, которых нет ни в одном существующем протоколе remoting'а
S>>Совершенно верно. В идеале, вместо SQL был бы нормальный язык высокого уровня, который бы не приносил такого страшного performance penalty на не-SQL операциях. C>Еще он сам по себе слишком жуткий по сравнению даже с VB.
Это да.
S>>Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется. S>>Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы. C>Ну это возможно, во всяких там DB2 и прочих — там процедуры компилируются в С, а потом и в машинный код.
Интересно бы глянуть на их данные по производительности.
S>>Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен. C>Тогда будет ваша проблема с кучей мелких тривиальных операций.
Ее можно решить, введя в протокол понятие группы операций, запрашиваемых одним запросом. C>Кстати, и HTTP не так уж удачен для многих задач.
Да. Хотя вон народ по нему и видео стримает...
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.