Re: Nested Transactions, Abort All

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.

Thanks,

-Min