简体   繁体   中英

EJB Container Manage transaction execution

In the J2EE doc it says,

Although beans with container-managed transactions require less coding, they have one limitation: When a method is executing, it can be associated with either a single transaction or no transaction at all.

Question 1. But what i understand is unless we declare transaction attribute with NotSupported or Never, when the method is executing (suppose with default Required attribute) its guaranteed the method to be run with in a transaction right?

Also I need to know suppose with container manager transaction with default Required attribute below pseudo code happening,

class bean1{
 public void m1(){
    bean2.m2();
 }
}

class bean2{
 public void m2(){
 }
}

**Question 2.**In this case does m2() in bean2 ran with in a new transaction or ran under same transaction for m1() in bean1?

Question 1. But what i understand is unless we declare transaction attribute with NotSupported or Never, when the method is executing (suppose with default Required attribute) its guaranteed the method to be run with in a transaction right?

Yes, the default for container-managed transaction is Required, which will start a transaction if one does not exist. The paragraph you quoted is somewhat unusual (obviously either a transaction exists or not), so I'm missing context to give a more complete explanation.

Question 2. In this case does m2() in bean2 ran with in a new transaction or ran under same transaction for m1() in bean1?

Assuming they are both EJBs and no other transaction attributes are applied (ie, both EJB methods are using the default Required attribute), then both methods will use the same transaction. The semantics for all the transaction attributes are described succinctly in the javadoc for TransactionAttributeType .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM