Propagation behaviour of transaction

I am using annotation based declarative approach for spring aop. sample code

ClassA{
@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
add()
{
method1();
method2();
method3();

}
}

But I have still doubt on use of propagation.does propagation.Requires_New means that each request will start new transaction.

Second question:

Does failure of any method like method2,method3 will cause the transaction to rollback?

I will be very happy if any can help me to leans transaction propagation.

can someone provide me a real world example where we need a part开发者_运维问答icipate in existing transaction.because I visualise that add function that we are using in above example will be independent for all users,or any other function will be independent to each user who is calling. I am not able to find example where other propagation behaviour like PROPAGATION_SUPPORTS ,PROPAGATION_MANDATORY,PROPAGATION_REQUIRES_NEW etc. are used

Answering this comment, not the actual question:

transaction are session specific or request specific – Vish 3 hours ago

Neither. request and session are both web-specific scopes, while the Spring Transaction abstraction has nothing to do with web technologies.

The scope of @Transactional is per method invocation, as @Transactional is implemented through Spring AOP. The transactional state is kept in ThreadLocal variables which are initialized when the outermost @Transactional method is entered and cleared with commit or rollback when it is left. This whole abstraction works on Java method level, and hence does not require or profit from a web container.

And in response to this Question in the comment below:

thanks @sean,i am stil not able to get answer where other propagation behaviour like PROPAGATION_SUPPORTS ,PROPAGATION_MANDATORY,PROPAGATION_REQUIRES_NEW etc are used. please refer above for whole question

Here's the list of Propagation values with my comments:

MANDATORY
Support a current transaction, throw an exception if none exists.

Does not start a new Transaction, just checks whether a transaction is active (must be inside either another @Transactional method call or a programmatically created transaction)

NESTED
Execute within a nested transaction if a current transaction exists, behave like PROPAGATION_REQUIRED else.

Start a nested transaction if a transaction exists, start a new transaction otherwise.

NEVER
Execute non-transactionally, throw an exception if a transaction exists.

Does not start a transaction. Fails if a transaction is present.

NOT_SUPPORTED
Execute non-transactionally, suspend the current transaction if one exists.

Does not start a transaction. Suspends any existing transaction.

REQUIRED
Support a current transaction, create a new one if none exists.

If a transaction exists, use that, if not, create a new one. In 95% of cases, this is what you need.

REQUIRES_NEW
Create a new transaction, suspend the current transaction if one exists.

Always creates a new transaction, no matter if an existing transaction is present. If there is, it will be suspended for the duration of this method execution.

SUPPORTS
Support a current transaction, execute non-transactionally if none exists.

Can use a transaction if one is present, but doesn't need one (and won't start a new one either)

In most cases, REQUIRED is what you need (hence it's the default in the @Transactional annotation). I have personally never seen any other value but REQUIRED and REQUIRES_NEW in use.

Transaction propagation indicates what should be the behaviour of the given method when it is invoked. REQUIRES_NEW means that a new transaction should always be started, even if there is an ongoing transaction.

If method1(), for example, defines REQUIRES_NEW, than it will execute in a new transaction.

An exception will rollback the current active transaction, yes.

Yes. Requires_New means that each request will start new transaction. and Yes failure in method2,method3 will cause the transaction to rollback, depending on the rollback properties. check Transactional properties.