Re: Nested Transactions, Abort All

Min Xu (Hsu) wrote:
> Dear all,
>
> I've being following the discussion of the nested transaction. I
> apologize for that I can't help asking my questions as I get more
> confused about what exactly are nested transactions, at least as far as
> the concurrency control goes.
>
> It seems to me there are two different types of nested transactions,
> both to improve the parallelism to a transaction, but they have
> different semantics.
>
> The first type of nested transactions, I believe as described in this paper:
>
> http://portal.acm.org/citation.cfm?id=806709&dl=ACM&coll=portal
>
> has the semantics that the inner (or children) transactions are totally
> hidden within a outer (or parent) transaction. Concurrency control makes
> sure not only the entire (including children) parent transaction is
> serial with other (parent) transaction, but also all child transactions
> are serial inside the parent transaction. Clearly, this speedup the
> execution of the parent transaction when child transactions are executed
> in parallel. I think this semantics is also documented here:
>
> http://pybsddb.sourceforge.net/ref/transapp/nested.html
>
> On the other hand, I believe another semantics of nested transactions is
> that to allow child transactions to commit independently to the parent
> transaction. The logger example in this link given by a previous post
> in this discussion
>
> http://www.hk8.org/old_web/oracle/guide8i/ch02_05.htm
>
> is a good example on this semantics. As far as the concurrency control
> goes, the parent transaction and the children transactions are treated
> equally. I.e. if after a child transaction is finished and before its
> parent transaction commits, a conflict with the child transaction will
> not cause the parent transaction to rollback. Again, this allows more
> parallelism to the the parent transaction.
>
> Am I on the right track understanding the serializability semantics
> here? I'd appreciate it if someone can direct me some authorative text
> on these issues.

You are actually talking about much more powerful nested transactions
than we have implemented currently. The first allows for parallel
execution, which is certainly interesting. The second allows
subtransactions to be committed/rolled back independent of the outer
transaction. We don't support that either.

Our current implementation merely allows parts of a transaction to be
rolled back using ROLLBACK NESTED.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073