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