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 )
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 ?
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 support...you 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....