A transaction is nested, it will not be up-to-date until outmost transaction commits. So what is the concept of nested transaction and what's the problem that needs the feature?

for instance assume this type of situation:

Class A
{
 /// props
 save();
}

class B
{
  A a{get;set};
  // other props
  save();
}

now when you wish in order to save B, you initially save A assume in preserving A you've some service requires verification or etc, this type of situation in preserving B (some verifications) which means you need rollback if B can't verified, you also should to rollback whenever you can't verify A so you ought to have nested one (actually Separation of concern induce to this, you are able to mix everything and also have a spaghetti code without nested transaction).

There's nothing known as Nested Transactions.

The only real transaction that SQL views, may be the outermost one. It is the one that is committed or perhaps is folded back. Nested Transactions are syntactically valid, that's all. Suppose you call a process from the inside a transaction, which procedure has transactions itself, the syntax enables you to definitely nest transactions, however the only person which has any effect may be the outermost.

edit: Reference here : http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(2630)-nested-transactions-are-real.aspx