Re: Autonomous Transaction is back

On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> Ah, you're missing how commits in ATX are expected to work. Let me
> illustrate:
>
> X (
> Data write A1
> call Y(
> Start ATX
> Data write B1
> Commit ATX
> )
> Data write A2
> Exception
> )
>
> In this workflow, B1 would be committed and persistent. Neither A1 nor
> A2 would be committed, or visible to other users. Depending on what
> implementation we end up with, A1 might not even be visible to Y().
>
> So that solves your use case without any need to "block" ATXs in called
> functions. However, it leads to some interesting cases involving
> self-deadlocks; see the original post on this thread.
>
>
I don't follow. In your example above, if I'm X(), how do I ensure Y()
won't have committed anyting at all when I later at "Exception" decide to
rollback everything from "Data write A1" to "Data write A2" including any
writes made by Y() (in the example "Data write B1")?

I understand the "Exception" will take care of rollbacking my (X's) writes,
but that's not sufficient if you want to make sure you rollback
*everything*, including any writes made by functions you call.

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.