Нет. WMQ имеет упреждающее чтение, при котором непостоянные сообщения передаются клиенту, но даже в этом случае клиент выполняет один GET (или эквивалент языка) для каждого сообщения.
Предполагается, что одним из атрибутов асинхронного обмена сообщениями является то, что сообщения являются атомарными. Любая зависимость сообщений от других сообщений называется сходством, а сходство сообщений нарушает асинхронную модель. (Однако каждый транспорт делает некоторые приспособления для сродства, и группировка сообщений является примером этого.) Таким образом, GET — это атомарная единица работы, которая имеет соответствие 1:1 сообщению.
Сообщения WMQ могут иметь произвольный размер до 100 МБ, а сообщения большего размера могут быть сегментированы, когда одно логическое сообщение разбивается на несколько физических сообщений. В случае сегментированного сообщения одно GET приведет к потреблению нескольких сообщений, однако приложению возвращается только одно логическое сообщение.
Каналы WMQ используют пакеты, и до недавнего времени они строились строго по количеству сообщений. Однако вышеупомянутая изменчивость размеров сообщений чрезвычайно затрудняла настройку каналов, если и большие, и маленькие сообщения проходили по одному и тому же каналу. В v7.1 пакеты каналов WMQ теперь ограничены количеством сообщений или количеством байтов, в зависимости от того, что произойдет раньше. Любая концепция пакетной обработки сообщений GET потребует аналогичных функций настройки, чтобы предотвратить серьезное воздействие на память. Будут дополнительные взаимодействия с ведением журнала, размерами очередей и т. д. Также обратите внимание, что в случае сбоя одного сообщения необходимо будет откатить весь пакет.
Если целью является повышение производительности, используйте транзакции. При получении сообщений в точке синхронизации вы можете настроить количество сообщений на GET между COMMIT вызовами. Вы можете значительно улучшить производительность с интервалами COMMIT > 1, однако это значение падает выше порогового значения, которое вы можете определить методом проб и ошибок. Отчеты о производительности могут помочь определить наилучшее число для вашей платформы. Они доступны на главной странице SupportPacs. Найдите записи с такими именами, как MPxx.
Если сообщения непостоянны и вы можете позволить себе потерять некоторые из них при отключении, то вы можете использовать упреждающее чтение — при условии, что у вас современная версия WMQ. Это будет передавать сообщения клиенту WMQ приложения, так что следующее сообщение уже находится в локальном буфере, когда вызывается GET.
Кстати, ссылка в исходном посте была на документы WMB. Документацию по WMQ можно найти здесь.
person
T.Rob
schedule
27.01.2012
