Такая ситуация на практике часта? Или же всетке исключительна?

Можешь привести какойнить нормальный, внятный пример? В пику сферического в вакууме, высосанного из пальца мной. Я так понимаю ты уже обжигался на этом.
Те примеры, которые приходят мне в голову - заведомо плохая практика. Необходимость в завершении транзакций в процедуре если и возникает, то, обычно речь идет о процессах, инициируемых самим сервером. Логика таких процедур должна подразумевать повторное выполнение, в случае неуспешности выполнения. Работают такие процедуры, соответственно под контролем механизма транзакций оракла. Опасности тут не вижу. Если же процесс инициируется клиенстким приложением, то и транзакцией должно управлять клиенское приложение. Фиксация транзакции в процедуре, в таком случае - моветон.

Если вернуться к примеру, который приводил я. После восстановления работы, так ранее и не выполнявшаяся до конца процедура должна будет выполниться сызнова и дополнить недостающие данные.

Это сообщение отредактировал(а) Zloxa - 19.3.2013, 14:54

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

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

Внешний сервис может полезть в базу, за данными которые уже якобы закомичены.