gardenman - дык "duration of the connection" это не до ближайшего commit.

Herr Developer - могу попытаться рассказать, как я имел дело с длинной бизнес транзакцией.
Пусть длинная бизнес транзакция будет именоваться Unit of Work (UoW), и это не равно транзакции базы данных - это логическая бизнес транзакция. Приходит пакет данных, которые должны быть обязательно обработаны.
Допустим, что она достаточно велика - ну пусть 60 SQL Statements. И в любом случыае эти 60 statements будут выполнены, независимо от разных условий.
Допустим, у нас есть первый обработчик, который выполняет 30 statements и отправляет сообщение (задание) второму обработчику в рамках ОДНОЙ транзакциии с коммитом в базу
Допустим, второй обработчик гарантировано и однократно получает задание от первого, выполняет свои 30 statements, и отправляет задание третьему в рамках опять же одной транзакции с коммитом в базу.
С третьим обработчиком картина повторяется.
Имеем 3 транзакции по 30 statements вместо одной на 60. И бизнес транзакция выполнена, хоть и разнесена по трем. Причем, наличие гарантированности доставки заданий, управление заданиями в очередях по приоритетам, асинхронность, регулируемость кол-ва обработчиков каждого типа - позволяют управлять нагрузкой на сервер базы и в целом ведет к повышению пропускной способности.

По поводу интерактивной работы юзверей. Как я писал, у меня свои тараканы в голове. Поэтому я проектировал работу юзверей с базой путем отправки пользователями запросов на обслуживание посредством системы очередей. Опять же, приоритетность обработки (по типу юзверя/приложения/запроса), асинхронность,и QP как управление собственно запросами - позволяет поднять пропускную способность системы. Большой минус - из вещей типа PHP такое не сделать. Зато выигрышей много за счет асинхронности/приоритетности.
Я не хочу утверждать, что любую задачу можно привести к этой схеме. Но я так делаю, и если задача в это не будет вписыватся (по любым причинам) то это значит, что я ее не буду решать.

gardtnman - извини, щас токо разглядел, что вопрос по z/OS DB2.

Herr Developer - pSeries приобретается в собственность.

да не вопрос - можно.
Но по сути, читая лицензии на софт, который мы якобы приобретаем, можно выяснить, что приобретаем мы всего-лишь право на использование, за некую цену.
Учитывая длительность жизненного цикла современого софта и тенденцию к его сокращению, почему не взимать плату мелкими порциями в течении всего цикла? Суть то не меняяется - право на использование и все.
Ну это уже сапсем глубокий философский офф-топ