Re[48]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 29.09.07 21:49
Оценка:
Здравствуйте, kuj, Вы писали:

A>>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?

kuj>То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....

То есть мне интересно можешь ли ты написать в сообщении что-либо кроме оскорбления оппонента. Например, развёрнутый ответ на поставленный вопросы, а не ссылки на многокилломентровые статьи где якобы есть ответы, хотя их там совсем нет. Даже процитировать нужные отрывки статей на которые ссылаешься, ты не в состоянии.
Гугл такая штука, в нём можно найти всё что угодно. Например я могу в гугле найти стайтов сто одобряющих фашизм. Это же не значит, что фашизм хорошо, не так ли? Аналогично и тут, то что в гугле есть так или иная информация об обработке бизнес-транзакций вовсе не означает что информация верная. Гугл — поисковая система, а не энциклопедия и за корректностью информации никак не следит. Ссылаться в гугл можно когда тебя спрашивают "чему равно число пи?" или "как называется функция открытия файла?". В данном случае ссылка на гугл неадекватна.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[49]: Оформление работы с БД в корпоративных приложениях -
От: kuj  
Дата: 29.09.07 21:51
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?

kuj>>То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....

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

A>Гугл такая штука, в нём можно найти всё что угодно. Например я могу в гугле найти стайтов сто одобряющих фашизм. Это же не значит, что фашизм хорошо, не так ли? Аналогично и тут, то что в гугле есть так или иная информация об обработке бизнес-транзакций вовсе не означает что информация верная. Гугл — поисковая система, а не энциклопедия и за корректностью информации никак не следит. Ссылаться в гугл можно когда тебя спрашивают "чему равно число пи?" или "как называется функция открытия файла?". В данном случае ссылка на гугл неадекватна.

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

Горбатого могила выправит.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[48]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 29.09.07 21:52
Оценка:
Здравствуйте, kuj, Вы писали:

A>>ОК пришло подтверждение и тут же вырубилась сеть. Получается SMS есть, а юзера нет. Как ни крути, а целостность ты не обеспечишь.

kuj>Н-дааа..... Может Вы бот? Такой непроходимой тупости я еще не встречал... — про SMS я уже говорил и давал пример решения этой проблемы пару сообщений тому назад.

Не хами.

Вот хронология:
1. Запрос на создание пользователя.
(сбой в данный период не приводит к негативным последствиям)
2. Сохранение запроса
(сбой в данный период не приводит к негативным последствиям)
3. Запрос на создание машины
(сбой в данный период не приводит к негативным последствиям)
4. Сохранение запроса
(сбой в данный период не приводит к негативным последствиям)
5. Отсылка SMS
(сбой в данный период приводит к откату)
6. Получение подтверждения доставки SMS
(сбой в данный период приводит к несогласованному состоянию БД. SMS доставлен, но данные в БД не записаны)
7. Запись ранее сохранённых запросов.

Какие у тебя есть возражения по существу?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[50]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 29.09.07 21:58
Оценка: +1
Здравствуйте, kuj, Вы писали:

kuj>Я понял. Вы бот. Флейм-бот. Нормальный человек в здравом уме такой ахинеи нести не может. Я прекращаю этот спор в одностороннем порядке.

kuj>Горбатого могила выправит.

Слив защитан. по чуществу тебе сказать нечего и ты решил гордо удалиться. Не выйдет. Ты доказал исключительно свою неспособность ответить на элементарные практические вопросы.
A journey of a thousand miles must begin with a single step © Lau Tsu
[от модератора]
От: IT Россия linq2db.com
Дата: 29.09.07 22:21
Оценка: +1
Здесь уже было одно предупредиле о форме ведения дискуссии. Это последнее китайское.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Оформление работы с БД в корпоративных приложениях -
От: Cyberax Марс  
Дата: 30.09.07 02:55
Оценка: +2
Здравствуйте, adontz, Вы писали:

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

A>вот об том и речь., что ты не в состоянии дёшево отганизовать транзакции вне БД и делаешь две операции CreateUserWithCar и CreateCar имеющие много общего кода (копи-паст, если по простому).
Слушай, ты читаешь что тебе пишут вообще? Транзакции вне БД мне нафиг организовывать не нужно — в процессе регистрации в базу данных ничего не пишется.

Единственный момент, когда идет запись — это при завершении регистрации, когда у нас уже есть данные пользователя и данные хотя бы одного автомобиля. В виде псевдокода это можно предствить так:
Transaction trans=...;
trans.begin();
Session sess=getSessionWithPendingObjects();
sess.flush(); //Сбрасываем накопленые изменения.
trans.commit();


В результате, все операции типа CreateUser/CreateCar и им подобные выполняются вместе в одной транзакции.

Теперь понял?
Sapienti sat!
Re[37]: Оформление работы с БД в корпоративных приложениях -
От: Aviator  
Дата: 30.09.07 06:42
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


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

kuj>>Чушь.

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

Вам уже пора сделать тему adontz vs kuj , а то зафлудили всю ветку, читать уже невозможно.
Re[38]: Оформление работы с БД в корпоративных приложениях -
От: Светлояр Беларусь  
Дата: 30.09.07 10:37
Оценка:
Здравствуйте, Aviator, Вы писали:

A>Вам уже пора сделать тему adontz vs kuj , а то зафлудили всю ветку, читать уже невозможно.


Пусть в привате срутся.
Re[40]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 30.09.07 14:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Теперь понял?

Сам ты не читаешь Я уже сказал, что этот примитивный случай не интересен, поскольку теряется общность поставновки задачи. У тебя всё в БД, поэтому ты можешь обойтись транзакциями уровня БД. В задаче с отсылкой SMS это не так.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[39]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 30.09.07 14:34
Оценка: :)
Здравствуйте, Светлояр, Вы писали:

С>Пусть в привате срутся.


Зачем же ущемлять права эксгибиционистов?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[41]: Оформление работы с БД в корпоративных приложениях -
От: Cyberax Марс  
Дата: 30.09.07 14:44
Оценка: +1
Здравствуйте, 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]: Оформление работы с БД в корпоративных приложениях -
От: Cyberax Марс  
Дата: 30.09.07 15:02
Оценка:
Здравствуйте, adontz, Вы писали:

Как бы это сделал я.

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]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 30.09.07 17:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются.


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

Однако этот путьн е без проблем. Во-первых, хотя для большинства приложений это и работает, всё же бывают ситуации когда действие ну никак в БД не впихивается. во-вторых, транзакции это ещё и уровень изоляции. Не зная потрохов SQL запросов можно запросто словить дедлок указав изначально слишком низкий уровень изоляции. Указав слишком высокий получишь starvation. вобщем свои проблемы, помимо чисто идеологических, у этого подхода тоже есть.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[50]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 30.09.07 17:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Как бы это сделал я.

Что такое у тебя XA-транзакция?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[51]: Оформление работы с БД в корпоративных приложениях -
От: Cyberax Марс  
Дата: 30.09.07 17:13
Оценка:
Здравствуйте, adontz, Вы писали:

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

C>>Как бы это сделал я.
A>Что такое у тебя XA-транзакция?
Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit
Sapienti sat!
Re[43]: Оформление работы с БД в корпоративных приложениях -
От: Cyberax Марс  
Дата: 30.09.07 17:18
Оценка: +1
Здравствуйте, adontz, Вы писали:

C>>А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются.

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

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

Мне пока не попадались. Хотя в некоторых случаях действительно приходилось делать приседания.

Хотя, в принципе, и для таких случаев есть всякие BPMы (Business Process Manager'ы) с поддержкой компенсирующих транзакций.

A>во-вторых, транзакции это ещё и уровень изоляции. Не зная потрохов SQL запросов можно запросто словить дедлок указав изначально слишком низкий уровень изоляции. Указав слишком высокий получишь starvation. вобщем свои проблемы, помимо чисто идеологических, у этого подхода тоже есть.

У меня ни разу еще не появлялось надобности в изоляции больше READ COMMITED. А дедлоки очень эффективно обходятся с помощью оптимистического версирования (поэтому оно мне так и нравится).
Sapienti sat!
Re[52]: Оформление работы с БД в корпоративных приложениях -
От: adontz Грузия http://adontz.wordpress.com/
Дата: 30.09.07 17:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Как бы это сделал я.

A>>Что такое у тебя XA-транзакция?
C>Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit

Оно конечно здорово, но вроде кластерная штукенция. То есть, скажем, на SQL Server Express (Standard) этого нет и не будет если я правильно понял что это и зачем.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[53]: Оформление работы с БД в корпоративных приложениях -
От: Cyberax Марс  
Дата: 30.09.07 17:53
Оценка:
Здравствуйте, 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]: Оформление работы с БД в корпоративных приложениях -
От: nicolas1  
Дата: 01.10.07 00:17
Оценка:
Здравствуйте, 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]: Оформление работы с БД в корпоративных приложениях -
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.07 03:09
Оценка:
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.