Добрый день.

Нужно делать commit или нет - это от логики вашего приложения зависит.
Если логике - всё равно, то лучше делать, т.к. блокировки действительно могут сниматься.
А вот какие именно блокировки запросом накладываются, зависит от уровня изоляции, который используется для запроса.
По умолчанию это CS (блокируется только запись, на которой курсор позиционирован) и при этом после выполнения в командной строке db2:
db2 -c- "select * from x1"
указатель будет позиционирован за последней строкой курсора (а может быть оно после выполнения запроса вообще закрывает курсор), что не будет блокировать update любой строки.
Если охота поиграться с курсорами и разными уровнями изоляции и т.п., используйте:
И смотрите после open и каждого fetch, какие блокировки накладываются командой
для номера агента, соотв. вашей сессии.

IntserПоявился вопрос в котором хотелось бы разобраться досконально - не понятно поведение курсора при уровне CS без FOR UPDATE:
Судя по описанию блокировка накладывается на следующую запись - на деле другая сессия спокойно апдейтит и коммитит эту строку без всяких блокировок. Курсор фетчит старые данные. Не совсем понятно - откуда взялась старая версия данных? - они уже изменены другой транзакцией и изменения зафиксированы.Почитайте про OPEN там, где описан "Effect of temporary tables:".
В вашем случае, видимо, сначала делается open и для курсора формируется временная таблица.
Последующий update из другой сессии не оказывает влияние на содержимое этой временной таблицы, а значит и данных для курсора.
Если вы будете делать update ДО open, то open зависнет на формировании временной таблицы, т.к. open'у придётся для этого накладывать S-блокировку на каждую строку.