Вот всю последнюю неделю мучает в голове мысль. Пока у меня время терпит — могу думать и выбирать что и как делать. Ситуация такая — есть не очень большая БД. И к ней клиент.
Клиент собственно давно нужно было переписать вот этим и займусь. Но и БД нужно переделывать (и в ней есть огрехи и платформа меня не устраивает). Да и жизнь требует новой реализации.
Ситуация:
1. Работа по локалке.
2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?

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

F>Ситуация:
F>1. Работа по локалке.
F>2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
F>Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?
Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.

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

S>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.
ES? Это что такое?

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

F>Ситуация:
F>1. Работа по локалке.
F>2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
F>Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?

Почему нет? Если реализовать нечто вроде кэширования данных на клиентах (на случай проблем со связью у совсем удаленных клиентов ), асинхронное обновление/синхронизация этих данных в бэкграунде используя веб-сервис. Но если сильно большой объем информации, то может быть как нибудь иначе? При количестве записей в DataSet более 500000 возможны тормоза в плане производительности.
В принципе можно посмотреть и на .net remouting.
В любом случае вам лучше поподробней ознакомиться и с тем и с другим (тем более, что в какой то степени это родственные вещи (ремоутинг и веб-сервисы) ) и усиленно проанализировав все и вся определиться окончательно.

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

работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?
S>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.

ES — это EntepriceServices? COM+ уже поддерживает SOAP. Так что к таким компонентам можно обращаться как к Web Services.

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

F>Вот всю последнюю неделю мучает в голове мысль. Пока у меня время терпит — могу думать и выбирать что и как делать. Ситуация такая — есть не очень большая БД. И к ней клиент.
F>Клиент собственно давно нужно было переписать вот этим и займусь. Но и БД нужно переделывать (и в ней есть огрехи и платформа меня не устраивает). Да и жизнь требует новой реализации.
F>Ситуация:
F>1. Работа по локалке.
F>2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
F>Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?

А платформа, на основе которой вы собираетесь строить архитектуру системы?

С уваженеим,
bw.

Здравствуйте, <Аноним>, Вы писали:

А>А платформа, на основе которой вы собираетесь строить архитектуру системы?
.NET
Сервер однозначно Windows 2003.
Сервер БД — либо на нём же, либо Linux (если это будет не MSSQL).

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

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

S>>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.
F> ES? Это что такое?
EntepriceServices

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

S>>>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.
F>> ES? Это что такое?
S>EntepriceServices
Уже понял. Ладно, видимо нужно курить план и пробовать реализовать прототип.

А>>А платформа, на основе которой вы собираетесь строить архитектуру системы?
F> .NET
F> Сервер однозначно Windows 2003.
F> Сервер БД — либо на нём же, либо Linux (если это будет не MSSQL).
Если будут использоваться веб-сервисы под ASP.NET, тогда не обойтись без промежуточного слоя в силу специфики ASP.NET

С уважением,
bw.

Здравствуйте, <Аноним>, Вы писали:

F>> .NET
F>> Сервер однозначно Windows 2003.
F>> Сервер БД — либо на нём же, либо Linux (если это будет не MSSQL).
А>Если будут использоваться веб-сервисы под ASP.NET, тогда не обойтись без промежуточного слоя в силу специфики ASP.NET
А если по-подробнее?!

Веб сервисы — рулез Особенно когда надо разговаривать с SUN, TIBCO и прочими гиморами.
Enterprise Services — не сильно хорошо. В основном дает декларативный язык описания трансакций — гимор и Queued Components.

Для разделенных/удаленных систем лучше трансакции прописывать самому, т.к. тут основной геморрой в том, что ms sql любит короткие трансакции, а в случае разделенной системы короткие трансакции не сильно получаются — будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.

Оракл, с другой стороны, любит длинные трансакции, но не дружит с дот нетом. В частности сильно не дружит с DTC, на котором все эти трансакции и базируются. Плюс, все эти автоматические трансакции базируются на .NET Connection Pooling над которым в 1.1 нет никакого контроля. В 2.0 вроде бы обещают, но когда он появится этот 2.0? и когда его можно начинать использовать в production?

Вывод в общем такой: веб сервисы использовать стоит Это действительно легко и удобно. Но без трансакций

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

BG>Веб сервисы — рулез Особенно когда надо разговаривать с SUN, TIBCO и прочими гиморами.
Пожалуй разговаривать с богами солнец я не буду. А что такое TIBCO так и не знаю... Так что тут проще. А насчёт рулез — дааааааа! Чем больше ковыряю, тем больше нравится, но пока прототип еще не сделал — немогу никаких выводов сделать.

BG>Для разделенных/удаленных систем лучше трансакции прописывать самому, т.к. тут основной геморрой в том, что ms sql любит короткие трансакции, а в случае разделенной системы короткие трансакции не сильно получаются — будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
Ну может можно сначала залить xml файл, а потом уже его обрабатывать?!

BG>Оракл, с другой стороны, любит длинные трансакции, но не дружит с дот нетом. В частности сильно не дружит с DTC, на котором все эти трансакции и базируются. Плюс, все эти автоматические трансакции базируются на .NET Connection Pooling над которым в 1.1 нет никакого контроля. В 2.0 вроде бы обещают, но когда он появится этот 2.0? и когда его можно начинать использовать в production?
Насчёт 2.0 — то я думаю в этом году уже можно будет

BG>Вывод в общем такой: веб сервисы использовать стоит Это действительно легко и удобно. Но без трансакций
Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...

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

BG> будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
А кому нужна транзакция на скачивание xml-файла? Транзакция нужна когда идет обработка логики по полученным данным, а здесь уже можно сделать ее достаточно короткой практически всегда.

Здравствуйте, Merle, Вы писали:
BG>> будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
M>А кому нужна транзакция на скачивание xml-файла? Транзакция нужна когда идет обработка логики по полученным данным, а здесь уже можно сделать ее достаточно короткой практически всегда.

Судя по оценкам мнения разделились.
В случае распределенных трансакций — нужна.
Например тот же самый веб шоп. У Вас трех-звенка:
1. Front-End
2. Middleware
3. your Database

4. Credit Card Webservice.

Удобнее всего гнать транзакцию с номера 2. Т.к. 4. часто бывает сильно удаленным, трансакция получается распределенной. Вот Вам и закачка большого xml файла между участками 2/3 и 4. Домыслить остальное предоставляется читателю в качестве самостоятельно упражнения.

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

BG>>Веб сервисы — рулез Особенно когда надо разговаривать с SUN, TIBCO и прочими гиморами.
F> Пожалуй разговаривать с богами солнец я не буду. А что такое TIBCO так и не знаю... Так что тут проще. А насчёт рулез — дааааааа! Чем больше ковыряю, тем больше нравится, но пока прототип еще не сделал — немогу никаких выводов сделать.

Лучше Вам и не знать. Мне тоже лучше не знать. Хотя с точки зрения job security можно и подучить

F> Ну может можно сначала залить xml файл, а потом уже его обрабатывать?!

Распределенная трансакция — читайте предыдущий мессаг.

F> Насчёт 2.0 — то я думаю в этом году уже можно будет

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

F> Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...

Не занудствуйте — для здоровья, говорят, плохо. Сам то я не проверял, конечно.

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

BG>Если Вы любите играться с новыми технологиями — это очень полезно и хорошо. Я же люблю получать деньги за то, что делаю работающие продукты в срок и качественно. На проверенных технологиях.
Я предпочитаю работать с новыми технологиями. А насчёт проверенных — так разработку можно начинать уже, а ввод системы в рабочий стан в ближайшие пол года не планируется. Хм. Мне было бы даже привычно взять дотнет 1.1, но уж хочется вкусности.

F>> Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...
BG>Не занудствуйте — для здоровья, говорят, плохо. Сам то я не проверял, конечно.
Я просто поинтересовался почему так.

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

BG>Судя по оценкам мнения разделились.
Да не разделились, тот минус был скорее политический, иначе Мика рискнул бы изложить свои соображения...

BG>В случае распределенных трансакций — нужна.
Распределенные транзакции — это отдельная пестня, ну допустим нам приспичило делать их с помощю Web-сервисов...

BG>Например тот же самый веб шоп. У Вас трех-звенка:
BG>1. Front-End
BG>2. Middleware
BG>3. your Database

BG>4. Credit Card Webservice.

BG>Удобнее всего гнать транзакцию с номера 2. Т.к. 4. часто бывает сильно удаленным, трансакция получается распределенной.
Да не факт, удобнее разделить это на несколько транзакций.
1. заказ переводится в сосояние "ожидание оплаты" (2-3)
2. запрос на авторизацию кредитки через Web-сервис (2-4)
3. в случае успеха перевод заказа в состояние "ожидание отгрузки" и сообщения об этом радостном известии юзеру (3-2)
3а. в случае неуспеха заказ остается в состоянии "ожидание оплаты" и сообщается об этом печальном событии юзеру с просьбой повторить ввод.

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

BG>Вот Вам и закачка большого xml файла между участками 2/3 и 4.
Только 2-4 DB, таким образом, остается не затронутым и спокойно работает в привычном режиме.

BG> Домыслить остальное предоставляется читателю в качестве самостоятельно упражнения.
Еще примеры необходимости XML траффика в транзакции есть?

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

M>Никакой необходимости делать все в одной большой транзакции нет, однако с точки зрения юзера все выглядит так, как буд-то транзакция одна и большая.

Это я все к тому, что, как правило, нет необходимости вовлекать БД в пользовательские транзакции (кроме как посредством пользовательских блокировок, которые аккурат для этого и предназначены), особенно если оные транзакции шибко длинные и распределенные.

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

F>>> Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...
BG>>Не занудствуйте — для здоровья, говорят, плохо. Сам то я не проверял, конечно.
F> Я просто поинтересовался почему так.

В силу своего геогрфического положения, говорю, думаю и пишу по английски. Переводить хорошо не всегда получается Это как раз один из тех случаев.

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

BG>>Судя по оценкам мнения разделились.
M>Да не разделились, тот минус был скорее политический, иначе Мика рискнул бы изложить свои соображения...

Wild shot — wild miss on my part

BG>>В случае распределенных трансакций — нужна.
M>Распределенные транзакции — это отдельная пестня, ну допустим нам приспичило делать их с помощю Web-сервисов...

BG>>Например тот же самый веб шоп. У Вас трех-звенка:
BG>>1. Front-End
BG>>2. Middleware
BG>>3. your Database

BG>>4. Credit Card Webservice.

BG>>Удобнее всего гнать транзакцию с номера 2. Т.к. 4. часто бывает сильно удаленным, трансакция получается распределенной.
M>Да не факт, удобнее разделить это на несколько транзакций.
M>1. заказ переводится в сосояние "ожидание оплаты" (2-3)
M>2. запрос на авторизацию кредитки через Web-сервис (2-4)
M>3. в случае успеха перевод заказа в состояние "ожидание отгрузки" и сообщения об этом радостном известии юзеру (3-2)
M>3а. в случае неуспеха заказ остается в состоянии "ожидание оплаты" и сообщается об этом печальном событии юзеру с просьбой повторить ввод.

M>Никакой необходимости делать все в одной большой транзакции нет, однако с точки зрения юзера все выглядит так, как буд-то транзакция одна и большая.

Абсолютно с Вами согласен. Я не фанат распределенных и декларативных трансакций — т.к. их очень тяжело контролировать. К сожалению, технология двигается именно в направлении декларативных трансакций, поэтому хошь, не хошь, а связываться с ними приходиться. Я просто выбрал этот простой пример, что бы объяснить необходимость такого рода вещей.

Не очень хочу распространятся с чем именно счас приходится работать, но в общем ситуация такая:
1. есть главная оракловская база
2. есть второстепенная оракловская база
3. есть аудит сервис сделанный хрен знает на чем (не в курсе на чем он сделан, знаю только что железка стоит 50К) — на нас смотрит вебсервис, куда мы пихаем свои данные.
4. есть еще пара машин db2 — тоже с вебсервисами. — legacy
5. есть еще и страшный зверь TIBCO — на него мы тоже глядим через вебсервисы. — legacy

Наша группа занимается front end/middle ware — т.е. кастомер чей-то там кликнул и нам надо пускать трансакцию по всем пяти Data Sources. Ситуация почти как на микрософтовском экзамене, только вот в реальной жизни. Никогда не думал, что увижу такие вещи.

Иногда приходится и длинный xml туда сюда пихать в трансакции — некрасиво, конечно, но что делать?

BG>>Вот Вам и закачка большого xml файла между участками 2/3 и 4.
M>Только 2-4 DB, таким образом, остается не затронутым и спокойно работает в привычном режиме.

Я просто предложил академический пример, который все используют для объяснения ситуации. Вдаваться в тонкости архитектуры я счас не очень хочу. Ибо можно сделать проще, да. Но не всегда. К тому же эти решения часто бывают приняты очень давно и изменить их уже нельзя.

BG>> Домыслить остальное предоставляется читателю в качестве самостоятельно упражнения.
M>Еще примеры необходимости XML траффика в транзакции есть?

Да куча. Любой обмен информации с legacy источниками счас происходит именно через xml. Очень удобно кстати сказать, потому как не надо учить архаичную архитектуру AS400 или чего-нибудь там еще. Нам просто дают xml schema и усе

Здравствуйте, Merle, Вы писали:
M>>Никакой необходимости делать все в одной большой транзакции нет, однако с точки зрения юзера все выглядит так, как буд-то транзакция одна и большая.

M>Это я все к тому, что, как правило, нет необходимости вовлекать БД в пользовательские транзакции (кроме как посредством пользовательских блокировок, которые аккурат для этого и предназначены), особенно если оные транзакции шибко длинные и распределенные.

Опять же не сильно с Вами соглашусь. Я рассматриваю БД как persistance storage — т.е. все что туда попало, никогда уже без причины оттуда не выпадет. В этом смысле очень удобно использовать БД как механизм/контроллер управления трансакциями в Enterprise условиях. Оракл, кстати сказать, под это и заточен, поэтому я и написал, что он любит длинные трансакции и за ними очень хорошо следит.

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

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

BG>>Судя по оценкам мнения разделились.
M>Да не разделились, тот минус был скорее политический, иначе Мика рискнул бы изложить свои соображения...

Мерле, а если бы я тебе поставил знак "+" что бы ты тогда ответил?

Ладно, теперь по делу. То что ты описал, не совсем уж не правильно. Но есть и ошибка в твоих суждения.

BG> будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
А кому нужна транзакция на скачивание xml-файла? Транзакция нужна когда идет обработка логики по полученным данным, а здесь уже можно сделать ее достаточно короткой практически всегда.

Представь себе такую ситуацию. Размер закачиваемых данных очень большой, притом что клиент использует портативный тип ПО (смартафон). Логичнее всего при закачке сразу запустить процесс обработки данных, дабы не заставлять ждать пользователей несколько часов. При этом процессе могут происходить опять же ображение к другим источникам данных. Получается, что если наше первоначальное ображщение к серверу прервется, то должны откатиться все изменения.

Такая система может пригодится, например, при анализе рисков в предприятии. По полученным данным он сможет видеть как стоится график. Он может и не дожидаться окончания построения данных, увидев нужную картину, которая построилась по не полной информации (например, посмотреть динамику изменения вероятностей в начальный период).

Так же еще в твоем высказывании был такой спорный момент, что своим высказыванием ты фактически перечернул такую технологию как MQ, или WS-Transaction, где в рамках транспортной транзакции можно выполнять физические транзакции с источниками данных.

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

зы К сожалению у меня не так много времени в последнее время. Так что я ограничусь выражением своего мнение постановкой оценок. Надеюсь никто не против? Если уж что срочное, постараюсь отписать.

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

BG>Опять же не сильно с Вами соглашусь. Я рассматриваю БД как persistance storage — т.е. все что туда попало, никогда уже без причины оттуда не выпадет.
Да байта ради, что я — зверь какой? То что я изложил ни чуть этому не противоречит...

BG> В этом смысле очень удобно использовать БД как механизм/контроллер управления трансакциями в Enterprise условиях.
Удобно, вопрос только как именно.. Пихать в лоб длинную транзакцию в БД — не самое удачное решение...

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

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

BG> Я просто выбрал этот простой пример, что бы объяснить необходимость такого рода вещей.
Я нигде не говорил, что такой необходимости в принципе быть не может, и очень аккуратно употреблял всяческие "почти", "практически", ect.. Но, как правило, необходимость в подобного рода решениях обусловлена не чисто техническими соображениями, а скорее политическими "стоимость разработки", "обратная совместимость", ect..

BG>Я просто предложил академический пример, который все используют для объяснения ситуации.
А я дал академическое решение..

BG>Да куча. Любой обмен информации с legacy источниками счас происходит именно через xml. Очень удобно кстати сказать, потому как не надо учить архаичную архитектуру AS400 или чего-нибудь там еще. Нам просто дают xml schema и усе
Да понятно что xml, на БД транзакции-то этот xml зачем завязывать?
Я не говорю о всевозможных legacy конструкциях, но при решении таких распределенных задач, в общем случае, "правильным" подходом было бы использование некого координатора этих самых расперделенных транзакций. БД, при этом, используется только если координатору нужно хранить какие-то промежуточные состояния, и в случае сбоя координатор выполняет компенсирующие транзакции для отката состояний. При этом и БД не нагружена, и за длинными транзакциями следит механизм специально для этого предназначенный.

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

MS>Мерле, а если бы я тебе поставил знак "+" что бы ты тогда ответил?
А тогда бы расхождения во мнениях не было..

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

MS>Представь себе такую ситуацию. Размер закачиваемых данных очень большой, притом что клиент использует портативный тип ПО (смартафон). Логичнее всего при закачке сразу запустить процесс обработки данных, дабы не заставлять ждать пользователей несколько часов. При этом процессе могут происходить опять же ображение к другим источникам данных. Получается, что если наше первоначальное ображщение к серверу прервется, то должны откатиться все изменения.
Хм.. Ну, пример довольно сомнительный, а если речь идет именно про БД транзакции, то и вообще невозможный. Более того, собственно необходимости в БД транзакциях я здесь не вижу.

MS>Так же еще в твоем высказывании был такой спорный момент, что своим высказыванием ты фактически перечернул такую технологию как MQ, или WS-Transaction, где в рамках транспортной транзакции можно выполнять физические транзакции с источниками данных.
Вовсе нет. В рамках транспортной транзакции, БД транзакций может быть сколько угодно, но вот если эта транспортная транзакция выполняется в рамках БД транзакции, то здесь явно какой-то косяк...

MS>Если ты считаешь, что оценка не заслужена, то я могу ее убрать.
Да байта ради, это же твое мнение..

MS> Но я все же считаю, что ошибать — не зазороно. Хороший специалист имет право на ошибки.
Спасибо за комплимент, но пока вроде ошибок нет, что делает меня еще лучше..

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

BG>>Опять же не сильно с Вами соглашусь. Я рассматриваю БД как persistance storage — т.е. все что туда попало, никогда уже без причины оттуда не выпадет.
M>Да байта ради, что я — зверь какой? То что я изложил ни чуть этому не противоречит...

BG>> В этом смысле очень удобно использовать БД как механизм/контроллер управления трансакциями в Enterprise условиях.
M>Удобно, вопрос только как именно.. Пихать в лоб длинную транзакцию в БД — не самое удачное решение...

Вопрос по большей части философский. Возьмем такой сценарий:
К вам на файловую систему свалился бааальшой такой xml200504272152.OUT
Когда Вы начали с ним работать, Вам надо его переименовать в .INPROCESS, что бы другая нода (а их пара сотен) не взялась за этот же файл и не стала выполнять ту же саму работу, которую выполняет наша нода.
Вам его надо распихать по 5 различным базам данных.
Да так, что бы если одна из этих пяти баз данных (скажем номер 4) Вас обломала, Вам бы стоило вернуть все предыдущие в то состояние в котором они были, до начала Вашей операции.
И в зависимости от успеха предыдущей операции переименовать в xml*.IMPORTED или xml*.NOTVALID или ваапще удалить нах.

Скажем у вас есть w2k server, .net и оракл. Файловая система на текущий момент трансакционность не поддерживает, поэтому участниками/координаторами трансакций будут oracle, и ms dtc. Каждый из которых понимает трансакцию по своему.

Грубо говоря речь идет о семантическом расширении понятия транзакции Т.е. вместо одной базы данных, транзакция может включать в себя гораздо большее количество элементов — файловые системы (в недалеком будущем), веб сервисы, етц, етц. В этом смысле Enterprise Services и декларативное описание трансакций очень полезно, т.к. Вам не нужно вдаваться в подробности описания транзакций того или иного участника, а просто сказать, что все что внутри данного метода/класса должно выступать в качестве т. Согласить — это круто Я вот тоже так считаю, и все вот жду когда же это наконец заработает

BG>> Оракл, кстати сказать, под это и заточен, поэтому я и написал, что он любит длинные трансакции и за ними очень хорошо следит.
M>Вот тут я, пожалуй, немного не соглашусь длинные транзакции не любит никто, другое дело, что Оракл гораздо терпимее к ним относится.

Опять же вопрос понятийный. Но Вы и сами наверняка замечали, если Вы сидите и бьетесь головой об стену, пытаясь решить какую нибудь проблему, стоит Вам только подойти к кому-нибудь объяснить свою проблему словами, как решение придет само, еще до того, как Вам ответят. Решение приходит как только Вы заставили себя формализовать проблему. Так же и в этой дискуссии: можно долго сидеть и читать книжки по трансакциям и Enterprise Services, долбаться с академическими примерами (тот же самый веб шоп) и думать: на фига наращивать такой геморрой для простого веб шопа — можно ведь сделать и проще. Можно сделать и проще, да. Но на академических примерах можно научится решать только академические задачи — в реальной жизни все гораздо сложнее. Впрочем, что я Вам об этом рассказываю, Вы и сами об этом знаете

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

M>Здравствуйте, Mika Soukhov, Вы писали:

MS>>Мерле, а если бы я тебе поставил знак "+" что бы ты тогда ответил?
M>А тогда бы расхождения во мнениях не было..

Не знаю как у других, но я за неправильные ответ тебе + ставить не буду

MS>> Но есть и ошибка в твоих суждения.
M>Да вроде нет.
M>Похоже ты просто не уловил суть моих рассуждений. Они сводились не к тому, что я против передачи данных в транзакции,

Если бы ты такое опротестовал, то я думаю не только я бы тебе поставил минус

M>а к тому, что эта транзакция обязательно должна быть частью БД-транзакции. Видимо я не достаточно ясно выразился.

Доводы

MS>>Представь себе такую ситуацию. Размер закачиваемых данных очень большой, притом что клиент использует портативный тип ПО (смартафон). Логичнее всего при закачке сразу запустить процесс обработки данных, дабы не заставлять ждать пользователей несколько часов. При этом процессе могут происходить опять же ображение к другим источникам данных. Получается, что если наше первоначальное ображщение к серверу прервется, то должны откатиться все изменения.
M>Хм.. Ну, пример довольно сомнительный, а если речь идет именно про БД транзакции, то и вообще невозможный.

Ну почему же? Очень даже возможный. Мы открываем транзакцию и начинаем считывать посегментно файл. Если данные прерываются, в базу заносим запрос Rollback. Если все нормально, то Commit.

M>Более того, собственно необходимости в БД транзакциях я здесь не вижу.

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

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

Ну хоть с первым разобрались Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция. В ее рамках выполняется транспортная. В данном случае — это пересылка данных по протоколу TCP (напомнить, чем отличается он от UDP). Теперь повысим уровень асбтракции транспортной транзакции до MSMQ. Вуаля — твое утверждение не верно.

MS>>Если ты считаешь, что оценка не заслужена, то я могу ее убрать.
M>Да байта ради, это же твое мнение..

Ну вот видишь. А то политика, милитика

MS>> Но я все же считаю, что ошибать — не зазороно. Хороший специалист имет право на ошибки.
M>Спасибо за комплимент, но пока вроде ошибок нет, что делает меня еще лучше..

Правильно. Если себя не похвалишь, кто еще это сделает.

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

MS>Не знаю как у других, но я за неправильные ответ тебе + ставить не буду
Ну, за правильный мог бы, тем более, что сам явно что-то не то рассказываешь..

MS>Ну почему же? Очень даже возможный.
Работать с еще не зафиксированными данными ни одна вменяемая БД не даст.

MS>Мы открываем транзакцию и начинаем считывать посегментно файл. Если данные прерываются, в базу заносим запрос Rollback. Если все нормально, то Commit.
Зачем на этом этапе открывать БД транзакцию?

MS>Обработка данных — это процесс с их изменением. Если здесь не применять транзакцию, то при прерывании загрузки файла может случиться ситуация с несогласованностью данных.
Каким образом? загрузка — это только загрузка, если очень хочется во время этой загрузки как-то эти данные отображать — бога ради, но к БД это не имеет никакого отношения и в случае сбоя ни к каким проблемам не приведет.

MS> Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция.
Есть.

MS> В ее рамках выполняется транспортная.
Зачем? Откуда здесь взялась транспортная транзакция?

MS> В данном случае — это пересылка данных по протоколу TCP (напомнить, чем отличается он от UDP).
Пересылка данных происходит вне контекста транзакции.

MS> Теперь повысим уровень асбтракции транспортной транзакции до MSMQ. Вуаля — твое утверждение не верно.
Я нигде не утверждал, что так делать нельзя, я утверждал, что так делать не правильно. А то что способов прострелить себе ногу есть придостаточно — никто не спорит.

M>>Да байта ради, это же твое мнение..
MS>Ну вот видишь. А то политика, милитика
Политическое мнение, иначе ты не стал бы тут сейчас фантастические сценарии строить..

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

MS>Обработка данных — это процесс с их изменением. Если здесь не применять транзакцию, то при прерывании загрузки файла может случиться ситуация с несогласованностью данных.
Ни разу не встречал такого, чтобы нельзя было такую сверхдлинную транзакцию поделить на много маленьких. Нет, бывают, конечно, люди, которые утверждают, что "импорт справочника товаров" должен быть атомарным, но почему-то объяснить происхождение этого требования, бенефит от его выполнения, и каким дизастером чревато невыполнение, они мне так и не смогли.
M>>Вовсе нет. В рамках транспортной транзакции, БД транзакций может быть сколько угодно, но вот если эта транспортная транзакция выполняется в рамках БД транзакции, то здесь явно какой-то косяк...

MS>Ну хоть с первым разобрались Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция. В ее рамках выполняется транспортная.
Ага. Тебе уже написали, что это — косяк. Или я что-то не так понял? Ты намекаешь, что в рамках DB-транзакции можно вызывать MSMQ? Ну так это значит нифига не транспортная транзакция. Транспортная транзакция закончится тогда, когда данные доедут до получателя.

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

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

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

Я тоже так думаю. Только при чем здесь мой вариант и почему же она получается эдакая сверхдлинная?

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

Про импортирование — возможно асбурд. Но изменение — отнюдь.

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

MS>>Ну хоть с первым разобрались Давай теперь ко второму. Простейшая ситуация. Мы открываем транзакцию и в ее контексте изменяем пару записей. У нас есть БД транзакция. В ее рамках выполняется транспортная.
S>Ага. Тебе уже написали, что это — косяк. Или я что-то не так понял? Ты намекаешь, что в рамках DB-транзакции можно вызывать MSMQ? Ну так это значит нифига не транспортная транзакция.

Почему это? Главное — переслать данные в транзакции. А в рамках чего это будет происходить (хоть в рамках другой транзакции) — это не суть важно.

S>Транспортная транзакция закончится тогда, когда данные доедут до получателя.

Правильно.

Здравствуйте, Mika Soukhov, Вы писали:
MS>COM+ уже поддерживает SOAP. Так что к таким компонентам можно обращаться как к Web Services.

Ой! А можно подробнее...

А то я подумал может тут где-то и решение моей задачи лежит...
Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).
Требуется увидеть его на виндах как базу данных.
Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

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

EXO>Здравствуйте, Mika Soukhov, Вы писали:
MS>>COM+ уже поддерживает SOAP. Так что к таким компонентам можно обращаться как к Web Services.

EXO>Ой! А можно подробнее...

EXO>А то я подумал может тут где-то и решение моей задачи лежит...
EXO>Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).

А что, под Unix уже COM+ портировали?

EXO>Требуется увидеть его на виндах как базу данных.
EXO>Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

Под Windows на чем пишешь? Если .NET, то вообще проблем нет. Добавляшь в проект Add Web Reference....

Здравствуйте, Mika Soukhov, Вы писали:
EXO>>Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).
MS>А что, под Unix уже COM+ портировали?

Почему? Веб сервисы через SOAP. Они там давно есть...

EXO>>Требуется увидеть его на виндах как базу данных.
EXO>>Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

MS>Под Windows на чем пишешь? Если .NET, то вообще проблем нет.
MS> Добавляшь в проект Add Web Reference....

На виндах есть уже готовая прога (не моя), которая работает с базами через OLE DB
Мне надо натравить ее на юниксовую апликуху (которая не есть БД, но может быть так представлена).
А для этого что-нибудь написать... или не писать.

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

EXO>>Задачка такая: есть продукт у которого есть интерфейс через SOAP (продукт под unix).

MS>А что, под Unix уже COM+ портировали?
А причем тут COM+? Вообще web сервисы и SOAP пришел от Java. И именно из-за того, что его все платформы обязались держать.

EXO>>Требуется увидеть его на виндах как базу данных.
EXO>>Я уж собирался свой OLE DB Provider писать... но может какое готовое решение есть?

MS>Под Windows на чем пишешь? Если .NET, то вообще проблем нет. Добавляшь в проект Add Web Reference....
Я бы сказал не только. В Net достаточно много удобных инструментов для работы с SOAP. Если другая платформа, то Soap Toolkit.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:
MS>>Под Windows на чем пишешь? Если .NET, то вообще проблем нет. Добавляшь в проект Add Web Reference....
GZ>Я бы сказал не только. В Net достаточно много удобных инструментов для работы с SOAP. Если другая платформа, то Soap Toolkit.

Не, с SOAP все понятно. Более того со стороны юниксовой программы у меня исходники есть.
Проблема с виндовой стороны. Мне надо прикинуться стандартным OLE DB! Иначе чужая виндовая прога меня просто не поймет.

Собственно говоря я с удовольствием бы вообще ничего не писал с виндовой стороны. Но не знаю как так выкрутиться.

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

EXO>Не, с SOAP все понятно. Более того со стороны юниксовой программы у меня исходники есть.
EXO>Проблема с виндовой стороны. Мне надо прикинуться стандартным OLE DB! Иначе чужая виндовая прога меня просто не поймет.
EXO>Собственно говоря я с удовольствием бы вообще ничего не писал с виндовой стороны. Но не знаю как так выкрутиться.
А напрямую общаться с web сервисом общаться им впадлу? Написание OleDB provider'a, даже несмотря на ATL helperные классы весьма неприятная вещь. В свое время подолбался.

С уважением, Gleb.

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

MS>>А что, под Unix уже COM+ портировали?

EXO>Почему? Веб сервисы через SOAP. Они там давно есть...

Вообще странно как. Я в исходном сообщении писал про COM+

EXO>На виндах есть уже готовая прога (не моя), которая работает с базами через OLE DB
EXO>Мне надо натравить ее на юниксовую апликуху (которая не есть БД, но может быть так представлена).
EXO>А для этого что-нибудь написать... или не писать.

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

Здравствуйте, GlebZ, Вы писали:
GZ>А напрямую общаться с web сервисом общаться им впадлу?

Впадлу. Команда разработчиков того продукта (дельфисты) про веб-сервисы знать не желают.

> Написание OleDB provider'a, даже несмотря на ATL helperные классы весьма неприятная вещь.
> В свое время подолбался.

Вот потому-то мне и не хочется... Но похоже придется.
А то я уж обрадовася, что может есть какой универсальный драйверок,
чтобы веб-сервис представить как Ole DB Provider.

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

EXO>Вот потому-то мне и не хочется... Но похоже придется.
EXO>А то я уж обрадовася, что может есть какой универсальный драйверок,
EXO>чтобы веб-сервис представить как Ole DB Provider.
Странно, в Delphi есть поддержка WebService. Есть другой выход. Если уж им так нравятся DataSet, то предоставлять им XML который они могут обрабатывать с помощью ClientDataSet. Это все-таки лучше и менее геморно, чем реализация OleDB Provider.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:
GZ>Странно, в Delphi есть поддержка WebService.

Я знаю что есть.

GZ> Есть другой выход. Если уж им так нравятся DataSet, то предоставлять им
GZ> XML который они могут обрабатывать с помощью ClientDataSet.
GZ> Это все-таки лучше и менее геморно, чем реализация OleDB Provider.

Технически ты абсолютно прав. Но к сожалению, для такого решения мне не хватает... ну скажем так — "административного ресурса".

Ситуация следующая:
1. Есть большое приложение сделанное в двухуровневой архитектуре.
2. В ходе развития системы стало много задач требующих сложной логики согласования/взаимодействия между сеансами пользователей. С усложнением задач рализация такого взаимодействия через тригеры в sql и временный таблицы стала громоздкой и ненадежной. Понадобился третий прикладной уровень.
3. Разработчики отказались что-либо менять (добавлять) в коде основного движка системы и ее архитектуре.

Единственная лазейка, которую мне пока удалось найти, это то, что дельфи-уровень системы никак не обрабатывает sql-опеаторы, передавая их как строки. Причем хранятся они в БД.
То есть если мне удастся подключить некий "прикладной движок" на серверной стороне и расширить синтаксис sql некоторыми прикладными командами предметной области, то дельфи-часть системы этого даже не заметит. Но для этого надо прикинуться OLE DB Provider-ом, поскольку никаких других способов общения "с внешним миром" в системе сейчас не заложено.

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

EXO>Единственная лазейка, которую мне пока удалось найти, это то, что дельфи-уровень системы никак не обрабатывает sql-опеаторы, передавая их как строки. Причем хранятся они в БД.
EXO>То есть если мне удастся подключить некий "прикладной движок" на серверной стороне и расширить синтаксис sql некоторыми прикладными командами предметной области, то дельфи-часть системы этого даже не заметит. Но для этого надо прикинуться OLE DB Provider-ом, поскольку никаких других способов общения "с внешним миром" в системе сейчас не заложено.
Еще один обходной маневр: может быть, удастся отползти заменой ихнего TConnection на твой TConnection? К чему я клоню: написать свою реализацию TConnection на порядок проще, нежели OLE DB провайдер. Твой вариант смахивает на "давайте напишем драйвер файловой системы, потому что наши программисты ничего кроме DBF знать не хотят". Вариант, но его стоимость сравнима со стоимостью написания всей системы с нуля.

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

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

S>Еще один обходной маневр: может быть, удастся отползти заменой ихнего TConnection на твой TConnection? К чему я клоню: написать свою реализацию TConnection на порядок проще, нежели OLE DB провайдер. Твой вариант смахивает на "давайте напишем драйвер файловой системы, потому что наши программисты ничего кроме DBF знать не хотят". Вариант, но его стоимость сравнима со стоимостью написания всей системы с нуля.


"Ну ты меня убиваешь..."

Жаль, что все так сложно...
Для твоего варианта надо, чтобы они включили в свой проект чужой код...
... вою будет... на все отделы. И скорее всего 1001 прична для отказа.

Здравствуйте, EXO, Вы писали:
EXO>Жаль, что все так сложно...
Да ничего сложного нет. Тут есть камрады с опытом разработки не то ODBC не то OLE DB провайдера. Как я понял, примерная стоимость — 15 человекомесяцев. Назови это своему руководству, и дельфисты просто бегом побегут переписывать свой код на вебсервисы.