ColtСон Веры Павловны,
Т.е., по-хорошему, надо в начале ХП прибить все внешние трансакции (так как доступ к данным у планируется только через ХП и внешние вмешательства недопустимы), и только потом переходить к собственно логике ХП (с открытием/закрытием трансакции).
ПыСы Хотя это уже больше смахивает на шаманские костыли
Бред сивой кобылы.

sphinx_mvМСУпропущено...

1. Залоченная таблица товаров в ритейле для всех систем интрасети сродни апокаллипсису. Товар не движется, отгрузка не производится, сальдо с бульдой не сводятся. Профит?
Ну, если у кого-то чего-то "не сводится" - тот С.С.З.Б.

У Вас сказывается отсутствие реальнго опыта "первой линии" саппорта : о наличии проблемы на сервере БД дежурный админ узнает в течение единиц секунд - специально для этого поднимаются средства мониторинга состояния сервера БД. Еще, через несколько секунд админ уже знает какой процесс, включая кто и откуда, какой командой и какую таблицу залочил. Еще несколько секунд на "убийство" процесса - и таблица оказывается уже разлоченой. А еще через минуту к "виновнику торжества" направляется "поздравительный комитет"... Собственно, после этого инцидент на сервере базы данных "ушел в историю".

В интернете среднее время таймаутов в он-лайн-шопах хорошо, если 1 минутой ограничивается - на каждый клик мышкой...
А тут ажно апокалипсис! Четыре всадника на горизонте... Ага... Машина с товаром простояла под погрузкой на одну минуту больше, а главбух увидел цифру в отчете на 2 минуты позже из-за разового, и, возможно, последнего (в этой организации) "прикола" какого-нибудь "местного шутника"... И кто у Вас от такого умер?
Я тебе десятый раз повторяю, ни одно серьезное ПО не будет проектироваться под 2 звена, это удел криворуких архитекторов, которые не умеют готовить честную трехзвенку. Гоняться за негодяями в интрасети - маразм без комментариев. Шареная операционная БД для интрасети - идиотизм, которыя я устал комментировать. Букварь в зубы по проектированию архитектуры от мс и вперед. Иначе так и стухнешь процедурным гавнокодером. Опыт твой оставляет желать лучшего.

PichМСУ, а почему 3-х звенку ?! Как Вы определяете требуемое количество уровней ?! Можете привести прямо сейчас формулу для определения N-tiers ? or N-layers ? Tier and Layer - какая между ними разница ? А если 4-Tiers and 5-Layers - такое приложение возможно ?! Так что такое 3-х звенка в Вашем понимании ?!
Если ты читал внимательно то, о чем я пишу, вопросов бы не задавал. Речь о n-звенной архитектуре, где n > 2. Трехзвенка приводится в частности, как самая распространенная.

PichМСУ! Секундочку .....
Как Вы определяете разницу между N-tier and N-layer ? В чем разница ?!
Это очень важный вопрос. Когда Вы говорите /ЗВЕНО/, я так понимаю это же не звено истребителей, правильно ?
Так что такое N-tier and N-layer ?
И что Вы понимаете под словом /ЗВЕНО/ ? (типа звеньевая полеводческой бригады) я, на самом деле, Вас не понимаю, о чем Вы хотите рассказать. Буду благодарен за разъяснение.
У тебя каша в голове. Tier - уровни, Layer - слои. Гугли.

PichМСУ! Спасибо за ответ. Когда ВЫ говорите /ЗВЕНО/, то что Вы имеете ввиду. Что Вы под этим словом понимаете ?
И например, в учебниках Microsoft? Вашему слову /ЗВЕНО/ какое слово соответствует ? напишите это слово по-английски, если можно. Заранее благодарю!
Ты там из танка вылазь уже
http://translate.google.ru/?tab=wT#ru/en/трехзвенная архитектура

sphinx_mvВы все сказали?
А подумать перед этим не пробовали - или такой привычки не имеете?
Я уже давно всё сказал, остался вот единственный непробиваемый гавнокодер, у которого отсутствует голова на плечахи думать он не умеет. Ему и жую.

sphinx_mvЯ посмотрю, куда Вы побежите, когда Ваш сервер приложений заDDoSят... Посмотрим, что Вам скажут пользователи, когда в один не самый подходящий момент на сервере приложений запустится сборщик мусора, а пользователям "внезапно" нужно будет "напечатать платежку"... Посмотрим, куда Вы побежите, когда окажется, что в серверной нет свободных стоек под новые сервера, чтобы "масштабировать" сервер приложений или балансировщик нагрузки... Посмотрим, куда Вы побежите, когда в самый неподходящий момент "упадет" Ваш балансировщик нагрузки... Совсем интересно будет, когда (совершенно случайно!) из-за ошибок на сервере приложении только что отпечатанный документ "куда-то исчезнет"...
Маленький, ддос атаки точно так же относятся и к твоей говно архитектуре. Помимо прочего (расширивание БД в интрасети), тебя точно так же можно и поддосить Или ты решил, что уберег свой софт от это напасти? Во-вторых, пример вообще не в тему - учи матчасть, с подобными атаки борятся не на прикладном уровне, а средствами маршрутизации (циски). Более мощные атаки мощностью от 2Гбит и выше: меняют IP-адрес атакуемого ресурса в DNS. Первый раз и далее периодически (N раз в день) ресурс обычно работает медленно (этап сканирования и выяснения типов атак), потом работа стабилизируется. Классика жанра. Садись, двойка.

sphinx_mvХотя нет... Вы никуда не побежите - потому что Вы свою "гениально спроектированную архитектуру" НИКОГДА использовать НЕ будете. Вам же задавался прямой недвусмысленный вопрос - сколько времени Вы реально сопроводждали хотя бы одну Вашу систему в реально нагруженной и отвественной обстановке. Ответить Вы постеснялись - не о чем Вам рассказывать. Вы только 3.14 здеть на форумах о своей невменяемой крутизне умеете. А с основным принципом теории надежности инженерных систем Вы не знакомы - а гласит он, что чем сложнее система, тем меньше ее надежность. Если бы Вы его знали, то не плодили бы бестолково налево и направо лишние физические уровни архитектуры.
Когда подрастешь и наберешься немного ума и перечитаешь свои глупости, которые изрыгает больное воображение, тебе станет стыдно. Ты ни имеешь опыта ни в разрезе проектирования систем, ни в разрезе реализации безопасности и ее контроля. Тупая мартышка, которую научили создавать не менее тупые хранимые процедуры в еще более тупой небезопасной двухзвенке - вот твой предел. Мне остается лишь только жалеть тебя, ибо даже глумиться не хочется.

sphinx_mvА ссылки на это "руководство по проектированию архитектуры от MS" - ну, этим же нужно каким-нибудь лохам впаривать свои индусами писаные продукты. Пипл хавает - почему бы и не "рекомендовать"! Тем более, что лохи читают не вчитываясь...
Это руководство писали технически грамотные люди, профессионалы. Ты не дорос еще даже до ногтя этих людей, чтобы что-то там из-под кустов вякать про лохов и индусов, бестолочь.

sphinx_mvКороче... Вы горы впереди видите? Ну так вот - это плинтус, до которого Вам еще предстоит профессионально расти...
Убей себя, неофит

sphinx_mvsphinx_mvпропущено...
Да, не задавайте Вы ему таких вопросов - он все равно не ответит!

А еще он постоянно ссылается на Enterprise Solution Patterns Using Microsoft .NET , НО ОН НИ РАЗУ НЕ ЧИТАЛ Deployment Patterns и еще более конкретный его раздел Deployment Plan :
Layered Application mostly concerns managing design dependencies between components, while Tiered Distribution concerns optimizing the runtime server configuration to meet system-level operational requirements. Therefore, the criteria for structuring your application into layers are fundamentally different from the criteria used for optimizing physical component deployment. For example, one of the driving forces for assigning components to layers is to minimize the dependencies between components in different layers. Conversely, a primary driver for optimizing component deployment is to match a component's resource consumption profile to an appropriate server. This implies that a direct mapping of layers to tiers is often not the best distribution strategy. For instance, the Open Systems Interconnection (OSI) network protocol stack reference model is structured into seven layers. Seven different servers, each hosting a separate layer, are not required or even recommended.


The people who structure the application into layers are often not the same people who structure the hardware infrastructure. People in these two groups often have different skill sets with few skills in common. For example, application architects focus on application components and the relationships between components, while system architects focus on the servers and the networks that connect them.


Each additional tier to which components must be deployed adds complexity, deployment effort, and cost. Deploying all components to one tier is relatively simple. As you add more tiers, it becomes harder to determine which component goes where. Similarly, it takes relatively little effort to deploy all of your components to one location; after you add additional tiers, though, you have to put extra effort into your build and deployment process to decide which component goes where. Finally, each additional tier adds fixed and recurring costs for the additional hardware composing the tier.


The components that compose your application each consume a different amount of resources such as memory, processor utilization, file handles, IO sockets, and disk space. There are two approaches for assigning components to tiers based on this force: specialized tiers and general purpose tiers. Specialized tiers are optimized for hosting components with specific resource utilization profiles. Because the servers in the specialized tier are optimized for a specific profile, each server can host many more components that meet that profile than can a generically configured server. Therefore, using specialized tiers usually results in more tiers with fewer servers per tier. On the other hand, servers in a general purpose tier are generically configured, and so the deployment decision basically becomes: how many components each server can hold before a given system resource is completely consumed. Using general purpose tiers usually results in fewer tiers with more servers per tier.


Different components have different operational requirements such as security, availability, and fault-tolerance. For example, components that are accessed from the Web have different security requirements than do components that are on the corporate side of the perimeter network (also known as DMZ, demilitarized zone, and screened subnet). The same two approaches described for the previous force work here as well. Specialized tiers can be added to host components with specific operational requirements, or a general purpose tier can be configured to meet all operational requirements.


Security requirements often drive you to add tiers, with each tier hosting components that have common security requirements. Beside the added complexity, deployment effort, and cost noted earlier, each additional tier adds to the overall security risk. Each additional tier also adds new servers and other infrastructure that must be secured.


Business, political, or legal considerations may require specific components of a solution to be hosted at specific geographic locations. For example, databases containing sensitive corporate information may need to be hosted at secure corporate data centers, while the application servers that contain the business logic may reside at a third-party hosting facility.


Every process and server boundary that a component invocation crosses adversely affects response time. Component invocations that cross process boundaries are several times slower than in-process invocations, while component invocations that cross the network are an order of magnitude slower than component invocations in the same process.


И в чем твой вброс, сам-то понял, о чем речь? Приводится пример семиуровнего OSI . По поводу расходов на каждый уровень, это само собой разумееющееся, каждый уровень нужно поддерживать и мониторить. Если бы твой убогий опыт хоть капельку умел работать и понимать технологию WCF, то вопросов бы не возникло по поводу "сложности" и "дороговизны". Это тебе не ремоутинг, тут всё намного проще, прозрачнее и мощнее. Поддерживать SOA не сложно и дешево, это не семизвенка, это тупо банальная трехзвенка, коих сейчас тыщи. Купи букварь и убей себя об него По поводу времени отклика я уже писал, разница в одну наносекунду по сравнению с двухзвенным вариантом - несущественная. А если еще добавить поддержку tcp байдингов в wcf (для интрасети), то скорость будет повыше, чем в твоем небезопасном соединении с БД напрямую. Десятый раз говорю: rtfm, чудо.