Is there a use case for nested autonomous transactions?

Question

I was trying to come up with a real life programming problem that could be best solved by using autonomous transactions within autonomous transactions but could not think of any.

Can you give me any ideas?

Edit:

I mean something like this:

PROCEDURE outer_procedure
IS
BEGIN
  -- some code
  auto_proc1;
END;
/

PROCEDURE auto_proc1
IS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  -- some code
  auto_proc2;
END;
/

PROCEDURE auto_proc2
IS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  -- some code
  NULL;
END;
/

Answer 1

It's could be bit of a stretch, but I believe that this is a relatively common case in integration scenarios:

I had a situation where I needed to invoke a third party program that relied upon data committed to the database, but my business logic running in the outer transaction relied on the return from this third party program. This required that I use a nested (autonomous) transaction for the data needed by the third party program, and a separate transaction for the data incorporating the return of the third party program.

Answer 2

Autonomous transactions can be usefull for situations like:

• When you want to log information about a transaction in a table, even if that transaction fails/is rolled back. If you would do that without autonomous transactions, the logging will be rolled back also.

• If you have a long transaction that needs a short lock on a table that is also used by other threads. If you do this in an autonomous transaction, the lock will be held shortly, even if the transaction takes a long time.