Я бы отличал случаи OLTP и DW применимо к DPF.
Все ниже мое имхо.
Поскольку у меня в голове свои тараканы, то случаи прямого коннекта клиента к базе я не рассматриваю.
Так вот случай SELECT стоит немного особняком, если возвращаемые данные равномерно размазаны по нодам, или если не известно, где данные.
Случаи INSERT/UPDATE/DELETE - для достижения макс производительности и снижения задержек целесообразнее всего делать коннект к ноде, которая имеет обрабатываемые данные. Узнать это можно с помощью scalar function DBPARTITIONNUM, если я не ошибаюсь.
Дальше пошли предположения (в том смысле, что я этого не делал)
Создем некую сущность (балансер), в задачу которого входит принятие запроса на выполнение действий от пользователя, определение ноды, куда пойдут (INSERT) или где будут правится/удалятся данные (UPDATE/DELETE), и перенаправление запроса на выполнение другой сущности (может быть, потоку в рамках балансера) который имеет коннект к нужной ноде.
Случай, когда запрос затрагивает больше одной строки, и все они принадлежат одной ноде, можно приравнять случаю с одной строкой.
А вот если зпрос на обработку затрагивает строки, находяшиеся на разных нодах, то поступать можно по разному - можно "забить" на все и сделать все с любой ноды, или разбить запрос на части по нодам и выполнить а) в режиме двухвазной транзакции; б) нескольких однофазныйх транзакций (смотреть надо по бизнес логике.
Явно серия из однофазных транзакций на нодах, владеющих данными, будет самый быстрый вариант. Если по бизнесу такое не возможно, то надо сравнивать производительность случая "все с одной" и двухфазной транзакции.
По своему опыту могу предположить, что при правильном архитектурном подходе, в большом количестве случаев можно свести одну большую транзакцию к последовательности маленькой, а если сделать еще и компенсационный откат (или тулзы его поддерживают) то в подавляющем большинстве случаев.
Другой вопрос, что это выходит за рамки db2, потребуется (навскидку) MQ, и Broker может тоже нонадобится (ну я с самого начала сказал, что случай прямого коннекта клиента к базе не рассматриваю, это вот про MQ как раз и было).
В принципе, можно замутить.
Но реализация будет сильно завязаны на бизнес логику.

то, что падала производительность - объяснимо.
Толку делать балансировку round robin если коннект попадает на ноду, где данных нет.
Сплошные потери на межнодовой коммуникации, а не выигрышь.
Так как "оффициальная" позиция такая, что нет таких OLTP задач клиентов, которые не покрывались бы каким либо сервером IBM по производительности целиком и полностью, то применение DPF для OLTP следует рассматривать в последнюю очередь.
Ну а если рассматривать - то (имхо) по выше приведенной схеме.
ИМХО фиолетово, какая база, какого вендора, shared disk or shared nothing, проблема имеет место быть везде, и везде приложения должны быть заточены под конкретные условия.
Да и не имхо это - есть доки, имхо :)

AvalancheОпеределять, где лежит строка сессии, стоит примерно столько же, сколько сбегать и ее обновить.
Заблуждение IMHO
Большое

Avalanche
- это давний спор между рекомендуемыми и возможными решениями применения мейнфрейма или кластера и здесь у каждого своя позиция, но аргументы всех сторон общеизвестны.

Уточняю - о mainframe речи небыло, только о p5

Avalanche- IBM'овский принцип разноса функциональности в разные продукты меня опять озадачивает.

Да нет, все понятно и логично.
IBM и не скрывает, что понятие "бизнес приложение" и "J2EE приложение" эквивалентны.
Так что в этом смысле все логично, сервер приложений предоставляет полное окружение, включая и балансировку, етс.

дык мы можем хоть соглашатся, хоть не соглашаться - мы повлиять не можем.
Но имхо понимая стремление IBM вытеснить весь бизнес под сервер приложения - я понимаю, почему управление распределением отдано на откуп ему же.
Вы можете не соглашатся сколько угодно, я просто попытался предположить, почему так сделано.

а по поводу разницы узнать, где лежат данные, или сбегать и обновить, понятно?
Просто узнать - функция, hash, а сбегать и обновить - network I/O и disk I/O