Я должен использовать MSMQ или Сервисного Брокера SQL для транзакций?
CreateObject создает COM-объект, поэтому ваш
Set MyApp = CreateObject("Excel.Application")
запускает новый процесс Excel. Используйте GetObject для «получения существующего объекта с указанным ProgID». См. это для теории и практики.
4 ответа
После того, как мое приложение было перенесено из Service Broker в MSMQ, мне пришлось бы проголосовать за использование MSMQ. Есть несколько факторов, которые необходимо учитывать, но большинство из них связано с тем, как вы используете ваши данные и где происходит обработка.
- Если обработка выполняется в базе данных? Service Broker
- Если это просто перемещение данных? Компонент Service Broker
- Выполнена ли обработка в коде .NET / COM? MSMQ
- Нужны ли вам удаленные распределенные транзакции (например, обработка на блоке, отличном от SQL)? MSMQ
- Нужно ли иметь возможность отправлять сообщения, когда пункт назначения не работает? MSMQ
- Вы хотите использовать nServiceBus, MassTransit, Rhino-ESB и т. Д.? MSMQ
Что нужно учитывать независимо от того, что вы выберете
- Откуда вы знаете состояние своей очереди? Оба варианта обрабатывают аварийное переключение по-разному. Например, Service Broker отключит вашу очередь в определенных сценариях, которые могут закрыть ваше приложение.
- Как вы будете составлять отчеты? Если вы уже используете таблицы SQL в своих отчетах, Service Broker может легко вписаться, поскольку это просто еще одна динамическая таблица. Если вы уже используете Performance Monitor , MSMQ может подойти лучше. У Service Broker действительно много счетчиков производительности, поэтому не позволяйте этому быть вашим единственным фактором.
- Как вы измеряете время работы? Это просто проверка того, что вы не потеряете транзакции, или вам нужно отвечать синхронно? Я обнаружил, что распределенная природа MSMQ позволяет увеличить время безотказной работы, поскольку основная очередь может выходить в автономный режим и ничего не терять. Принимая во внимание, что с Service Broker ваша база данных должна быть в сети, иначе вы проиграете.
- У вас уже есть опыт работы с одной из этих технологий? У обоих есть много деталей реализации, которые могут вернуться и укусить вас.
- Не имеет значения, какой выбор вы делаете, насколько легко переключиться на основную технологию очередей? Я рекомендую иметь общий интерфейс IQueue, для которого вы пишете конкретную реализацию. Таким образом, ваш выбор может быть легко изменен позже, если вы обнаружите, что сделали неправильный выбор. В конце концов, очередь - это просто очередь, и она не должна привязывать вас к конкретной реализации.
Я использовал MSMQ прежде и единственный объект, который я добавил бы к Вашему списку, необходимая как условие проверка на управление версиями. Я столкнулся с проблемой, где один сайт имел Сервер Win 2000 и поэтому MSMQ v.2, по сравнению с Сервером Win 2003 и MSMQ v3. Весь мой код.NET предназначался для v.3, и они не совместимы... или по крайней мере не легко так.
Просто соображение, если Вы идете путем MSMQ.
Ограничение размера сообщения в MSMQ остановило мои поиски в этом направлении. Я изучаю Service Broker для проекта.
Вам нужно иметь возможность отправлять сообщения, когда адресат не работает? MSMQ
Не понимаю почему? SSB может отправлять сообщения в отключенное место назначения без каких-либо проблем. Все эти сообщения попадают в очередь на передачу и будут доставлены, когда пункт назначения останется доступным.