Suppose you are designing today a JavaEE JSF web application. You have a choice on the one hand between making the methods of your CDI beans @Transactional, and on the other hand injecting (session stateless, or singleton) EJBs in the CDI beans, and then the methods of EJBs would be executed under CMT transactions. What would you prefer? Why? Is it just a matter of taste?

  • usually it's better to delegate stuff to the framwork, so i would say @Transactional. It's juste one annotation. Injecting session require configuration, the you need to call to open the transaction, do you work and close it in a finaly block, which makes you write quite a lot more code and so the risk to introduce bugs. – Walfrat Aug 24 '16 at 11:25
  • @Walfrat no, in JavaEE (EJB 3), the configuration of session beans is just as (or almost as) painless as putting a @ Transactional annotation (even more, this permits you to deploy the logic inside the EJB's to another server in the future, if there arises a need in doing so). And the transactions are container managed (by default), so there is no need to configure transactions unless you wish to change the default choices, which are usually enough. – John Donn Aug 24 '16 at 13:02
  • Well then i don't have a real answer from what you say there is a little advantage for injection session. – Walfrat Aug 24 '16 at 13:13
  • 1
    This discussion has important points stackoverflow.com/a/13504763/269514 – Gilberto Jul 11 '18 at 16:58

CDI should be your default programming model and stacking EJB beneath it should be done only if required because it's costly.

So the rule is: don't use EJB if it doesn't bring feature you don't have in CDI.

If you design a new application, start by using CDI managed beans (POJO) with @Transactional and make them EJB only if you need specific EJB features (component pool, async operation, remote call).

@Transactional is defined in JTA spec as an interceptor binding and your JTA implementation provides you the same service thru this interceptor than the CMT for EJB.

| improve this answer | |
  • 1
    This seems like a good rule. However from what I saw, EJB 3 are not considered "costly" - not from the point of view of configuration (@ Stateless on the bean, @ Local on the interface and @ EJB to inject in CDI bean or a validator), nor from the point of view of performance (local calls) and memory consumption (Adam Bien's blog). Actually, EJB 3 (especially singletons) seem to me a close analogue of services in Spring, which are isolated from the "presentation layer", so it doesn't seem to me such a bad design decision to use EJB even if in principle everything can be done with CDI beans only – John Donn Aug 25 '16 at 20:26
  • ..and of course any corrections to what I said in my previous comment are most welcome! – John Donn Aug 25 '16 at 20:31
  • You're right. EJB3 is not costly but it's not free. The same for CDI: not costly but not free. So stacking both cost more than using only one. So the idea is to use CDI and EJB when it brings missing feature in CDI managed bean. – Antoine Sabot-Durand Aug 26 '16 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.