New rule: Avoid autonomous transactions

[Philipp Salvisberg]

Tom Kyte wrote in the chapter "Autonomous Transactions" in "Expert Oracle Database Architecture", third edition, 2013 on page 300:

Before we take a look at how autonomous transactions work, I’d like to emphasize that this type of transaction is
a powerful and therefore dangerous tool when used improperly. The true need for an autonomous transaction is very
rare indeed. I would be very suspicious of any code that makes use of them—that code would get extra examination.
It is far too easy to accidentally introduce logical data integrity issues into a system using them.

and on page 305:

In my experience, that is the only truly valid use of an autonomous transaction—to log errors or informational
messages in a manner that can be committed independently of the parent transaction.

As a result, we should find pragma autonomous_transaction only in the PL/SQL package that writes to a logging/debugging table. And even there, it should be possible to organize the code in a way that only one autonomous transaction is required.

It will most likely not be possible to distinguish legitimate uses of autonomous transactions from illegitimate ones via static code analysis. However, since we expect exactly one autonomous transaction per application, the number of false positives is manageable.

I suggest to assign the following properties to this rule.

• Characteristics:

  • Reliability because of the risk of compromising the data integrity
  • Testability because this makes setup and teardown more elaborate because the default rollback mechanisms of frameworks like utPLSQL cannot be used.

• Severity: Blocker because of Reliability