On 7/27/15 6:40 PM, Jim Nasby wrote:
> 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.
It just occurred to me that another option would be to have an event
trigger for beginning an autonomous transaction.
> [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