File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes Transaction support of Session Beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Transaction support of Session Beans " Watch "Transaction support of Session Beans " New topic

Transaction support of Session Beans

Ravi Kiran Va
Ranch Hand

Joined: Apr 18, 2009
Posts: 2234

Hi ,

what is the advantage one will get if he goes for session Beans Transaction suppourt when using Hibernate as persistency layer ( I mean why should we go for session bean Transaction support when there is Hibernate Transaction support )

Please suggest your ideas.

Save India From Corruption - Anna Hazare.
Paul Sturrock

Joined: Apr 14, 2004
Posts: 10336

I'm not sure what you are asking here. Can you explain?

JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Ravi Kiran Va
Ranch Hand

Joined: Apr 18, 2009
Posts: 2234

Paul Sturrock wrote:I'm not sure what you are asking here. Can you explain?

sorry if it is the wrong forum i posted ??

Anyway the explanation is , in our Application we used CMT suppourt of stateless session Bean for Transaction Management instead of Hibernate Transaction API .
Recently i attended an interview , i said the samething to the interviewer , he is looking at me strangely and asked that only for Transaction Suppourt you are using EJB ??(Instead of doing it manually)

I said the decision is taken by our Architect and i just followed it , Is there anything wrong ?
Rahul Babbar
Ranch Hand

Joined: Jun 28, 2008
Posts: 210
Normally, the transactions should be started in the EJB instead of taking the Hibernate Transactional Support because
1) If your business process states that changes in two different modules should take place in a action done(from the UI or otherwise), you will make call to two different DAOs, so if you start the transaction in one DAO, it will be very difficult to "propagate" the existing transaction because you have coded the method in the second DAO to start a new transaction, but you want both these updates(or whatever db changes) to be part of the same transaction. So, its better to start the transaction in the EJB, call DAO of 1st module, and call the DAO of second module so that they can be in single transaction. If your DAOs can be called only from your module's EJB, you can always call from an EJB1 --> DAO1 and EJB1--> EJB2--> DAO2 so that they will be in the same transaction if the EJB2 has appropriate Transaction Attribute(like the default 'Required').
2) It is not worthwhile to start the transaction in the DAO, because you have to manually start and commit the transaction, and make sure that the session is closed, or if some exception comes, you have to rollback the transaction...and this you have to do for each methods....EJBs simplify this in a big way...So, unless you plan to use Spring to manage Transactions, using Hibernate DAOs as transaction controllers should be a big No.

Also, EJBs have lots of other uses apart from Transaction can use interceptors for Security or logging, you can delegate the work to be done to different modules...etc etc...

P.S. I dont think you should ever say in the interview that this is the work of the architect, so you dont know, it doesnt put a good impression...You should confess that you dont know the reason, try to explain what you think could be the reason, and most importantly, ask the interviewer the correct answer after you are done....

Rahul Babbar
I agree. Here's the link:
subject: Transaction support of Session Beans
It's not a secret anymore!