Case 1. ejb-jar.xml has trans-attribute as Required and transaction-type as Container
The transaction will be handled by the container. Which means, if A does not contain any transactional context, B will create a new one, and the methodY() will be in the newly created context.
If A contains a transactional context, the container will propogate this context to the method in B, which the 2 methods will be ran in the same context. And thus, if methodY() fails, the whole transactions for both methodX() and methodY() rollback.
If you decide to commit the transaction, you dont need to do anything. The container will help u to commit.
If you decide to rollback the transaction, you just need to call context.setRollbackOnly(), and the container will ensure that the transaction will not be committed.
Case 2. ejb-jar.xml has trans-attribute as Required and transaction-type as Bean-Managed
For BMP, you dont have to configure the transactional attribute, as the container will not do anything for you. Inside the code, you need to explicitly get the UserTransaction object, and start your transaction in methodX() by ut.begin(). This transaction context can be propogate to methodY() in B if and only if it is a stateful session bean (Note that Entity bean cannot be BMP in EJB 2.0). Then in methodY(), you need to decide whether the transaction is committed (ut.commit()) or rollback (ut.rollback()).
You can use Stateful Session Bean with transaction management
1. Bean-Managed Transaction (BMT) In a bean-managed transaction, the code in the session or message-driven bean explicitly marks the boundaries of the transaction. An entity bean cannot have bean-managed transactions; it must use container-managed transactions instead. 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. If this limitation will make coding your bean difficult, you should consider using bean-managed transactions.
BMT with session bean , you can control transaction with JDBC and JTA
2. Container-Managed Transaction (CMT) In an enterprise bean with container-managed transactions, the EJB container sets the boundaries of the transactions. You can use container-managed transactions with any type of enterprise bean: session, entity, or message-driven. Container-managed transactions simplify development because the enterprise bean code does not explicitly mark the transaction's boundaries. The code does not include statements that begin and end the transaction.
CMT use transaction attribute , it config in DD file.
Synchronizing a Session Bean's Instance Variables The SessionSynchronization interface, which is optional, allows you to synchronize the instance variables with their corresponding values in the database. The container invokes the SessionSynchronization methods--afterBegin, beforeCompletion, and afterCompletion--at each of the main stages of a transaction.
The afterBegin method informs the instance that a new transaction has begun. The container invokes afterBegin immediately before it invokes the business method. The afterBegin method is a good place to load the instance variables from the database. The BankBean class, for example, loads the checkingBalance and savingBalance variables in the afterBegin method:
Java Developer, Thailand
posted 15 years ago
It didnt give me any error while typing it as bean-managed in ejb-jar.xml file. I could still go ahead and do the same logic using Weblogic 7.0.
posted 15 years ago
Thanks Nicholas Cheung for ur post.
I was expecting the same results as mentioned in ur post.
I was inserting one records at a time in one table say table1 in methodyyy() and inserting another set of records in another table say table2 in methodxxx().
Methodyyy() was returning some error ie SQLException (error defined on purpose) whereas methodxxx() was able to insert records in the table successfully which was killing the entire purpose. Problem was both methodxxx() and methodyyy() should have rollbacked the transaction which never happened in my case.
Does this mean that transaction handled in both the methods were independant of each other?
Any updates or correct me if I am wrong.
posted 15 years ago
Hi somkiat puisungnoen,
The Session Bean is defined as Stateful only and not as Stateless as I am trying to handle transactions in both CMT and BMT just to evaluate which works before I implement the same in our project.
I was also trying using the DataSource object to get the Connection along with earlier tries with UserTransaction for connection.
Any ideas which one would serve my purpose
What do you have in that there bucket? It wouldn't be a tiny ad by any chance ...
Devious Experiments for a Truly Passive Greenhouse!