Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Transaction handling in Session Bean

 
Seetesh Hindlekar
Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have modified the Session facade to look like this :

Remote Session Bean A ==== Local Session Bean B

I have methodxxx() in Remote Session Bean A calling methodyyy() in Local Session Bean B

Both methodxxx() and methodyyy() are involved in inserting data in the database.

Please explain as of how transactions are handled when
Case 1.
ejb-jar.xml has trans-attribute as Required and transaction-type as Container

Case 2.
ejb-jar.xml has trans-attribute as Required and transaction-type as Bean-Managed

Rgds,

Seetesh
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ejb-jar.xml has trans-attribute as Required and transaction-type as Bean-Managed


How can you specify trans-attribute when the transaction type is BMT.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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()).

Hope this help.

Nick
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Forget to mention, if it is a stateless session bean, you cannot keep the transaction open after the end of the method, you MUST either commit it, or rollback it.

Nick
 
somkiat puisungnoen
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

JDBC


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.

1. Required
2. RequiresNew
3. Mandatory
4. NotSupported
5. Supports
6. Never

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:


 
Seetesh Hindlekar
Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Pradeep,

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.

Rgds,

Seetesh
 
Seetesh Hindlekar
Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,

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.

Rgds,

Seetesh
 
Seetesh Hindlekar
Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

Rgds,

Seetesh
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic