On 7/27/15 5:12 PM, Joel Jacobson wrote:
> Right now, when writing a function, if you raise an exception, you can
> be sure all writes you have made will be rollbacked, but your caller
> function might caught the exception and decide to carry on and commit
> work made before your function was called, but at least you can be
> confident your writes won't be committed as long as you don't caught the
> exception you raised in your own function. If I understand it correctly,
> that would change with the addition of Autonomous Transaction, unless
> given a way to prevent a function you call from starting and commiting
> a Autonomous Transaction. Wrong? If so, then please show how to prevent
> Y() from commiting the "Data write B1" in your example, I don't get it.
What's being described here doesn't make sense in either use case ([1] &
[2]), but I do understand the concern about what 3rd party software is
doing. It would be nice to have the ability to disallow and/or disable
autonomous transactions, but I don't see a practical way of doing that
other than introducing a new GUC. I'm not sure if it's worth that effort.
[1] the "batch process" use case: batches that still hold their own
transaction open don't gain anything.
[2] the "audit logging" case. If you didn't care about auditing
surviving regardless of a rollback then you wouldn't go to the extra
work of an autonomous transaction to begin with.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com