golovonometr,

"Классика" для WMQ:
1. Создать специальную локальную очередь для программы "триггер-монитор".
2. Запустить программу "триггер-монитор", указав созданную очередь в качестве входной.
3. Создать объект типа "процесс", в нем описать программу, которая будет запускаться для чтения сообщений в целевой очереди.
3. На целевой очереди (в которую поступают сообщения) поменять параметры, включив триггер на первое сообщение в очереди.
Указать очередь триггера (п.1) и процесс обработки (п.3)

Что будет происходить:
При поступлении первого сообщения в целевую очередь будет сгенерировано служебное (триггерное) сообщение в очередь триггер-монитора.
Триггер-монитор, получив сообщение прочитает из него имя процесса обработки и запустит программу, которая там указана.
Программа должна будет считать и обработать все сообщения в очереди, после чего завершить свою работу.
Триггерные сообщения будут генерироваться только тогда, когда запущена программа триггер-монитор.
Этот подход для данного случая не единственный и, возможно, не самый надежный.

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

Подробнее здесь: Grouping logical messages .

golovonometr,

Какое из двух приведенных решений имеется в виду? Триггер или группа сообщений?

Файл на вход поступает одним сообщением или несколькими? Если файл поступает на вход таким образом, что каждая строка(запись) формирует отдельное сообщение (?), то как раз Message Group может помочь. Или хочется распараллелить обработку каждой строки?

Для большей конкретики нужно более подробное описание задачи, что, откуда и в каком виде может приходить, какие Flow предполагаются, какой препроцессинг (тот же truncate) и когда нужен. На каких этапах нужен параллелизм?

golovonometrЕвгений Хабаровgolovonometr,

Какое из двух приведенных решений имеется в виду? Триггер или группа сообщений?

Файл на вход поступает одним сообщением или несколькими? Если файл поступает на вход таким образом, что каждая строка(запись) формирует отдельное сообщение (?), то как раз Message Group может помочь. Или хочется распараллелить обработку каждой строки?

Для большей конкретики нужно более подробное описание задачи, что, откуда и в каком виде может приходить, какие Flow предполагаются, какой препроцессинг (тот же truncate) и когда нужен. На каких этапах нужен параллелизм?

Да каждая строка формирует отдельное сообщение, и параллелить хочется. Например, чтение из файла распараллелить не получится, но оно происходит быстро. Этот процесс можно считать мгновенным, но вот преобразование и сохранение в бд (в другую систему). Может продолжаться довольно длительный период. И этот процесс просто напрашивается на параллельное выполнение.

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

Было бы очень хорошо совершить весь процесс за короткий промежуток времени

А анализ в каком именно месте происходят задержки есть? Т.е. проверено ли утверждение, что "расписывание" 100 строк файла в 100 потоков параллельно дает существенный выигрыш по времени по сравнению с "расписыванием" этих же 100 строк в один поток (последовательно)?

Сколько в среднем строк в файле? Каков средний размер файла и строки?
Сильно ли отличается алгоритм обработки строки, в зависимости от данных в этой строке?

Если каждая строка файла примерно одинакова и раскладывается по общему набору таблиц, то распараллеливание может дать не прирост, а просадку по производительности, т.к. будет открыто N-соединений с СУБД, будет идти параллельная вставка в единое подмножество таблиц, что может приводить к блокировкам и конкуренции за ресурсы СУБД.
Дополнительно, если каждая строка обрабатывается в отдельном потоке, то вопрос что делать, если файл обработался частично? Например обработались строки с 1 по 10, а на 11 - некорректные данные. В зависимости от технологии - может потребоваться откат для всего файла, в этом случае из параллельных потоков этого сделать нельзя, тк каждый поток будет отдельной транзакцией.

Т.е. если задержки на стороне СУБД - имеет смысл разбираться почему. Возможно, для ускорения работы нужно переделать код INSERT/UPDATE, чтобы задействовать пакетный режим, aka batch update (один prepare, много bindParams + addBatch, один execute).

Возможно, результат парсинга файла имеет смысл поместить во временной таблице(ах), и уже после этого выполнять SQL-операторы, которые перенесут данные из временных таблиц в целевые. Это может избавить от необходимости делать truncate,  тк временные таблицы автоматически будут удалены при commit или disconnect (зависит от опций создания и СУБД).
Если есть проблемы в скорости соединения между брокером и СУБД, возможно имеет смысл использовать исполнение прикладного кода на стороне СУБД (хранимые процедуры например), а на вход подавать либо сам файл, либо значения из каждой строки файла, либо заполненные временные таблицы, содержащие преобразованный файл.

Пока я считаю, что проблему с недостаточной производительностью можно решить более простым и прямым способом, нежели формированием отдельных сообщений на каждую строку файла и параллельной вставкой в СУБД этих данных.