1

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?

4
  • 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
    Commented Aug 24, 2016 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
    Commented Aug 24, 2016 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
    Commented Aug 24, 2016 at 13:13
  • 1
    This discussion has important points stackoverflow.com/a/13504763/269514
    – Gilberto
    Commented Jul 11, 2018 at 16:58

1 Answer 1

Reset to default
3

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.

3
  • 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
    Commented Aug 25, 2016 at 20:26
  • ..and of course any corrections to what I said in my previous comment are most welcome!
    – John Donn
    Commented Aug 25, 2016 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
    Commented Aug 26, 2016 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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