On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus <josh@agliodbs.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.