jpa 2.0 - What is the difference between @Inject and @EJB

Question

I'm currently learning the new Java EE 6 component models and am confused with the latest dependency injection mechanism. So here are my questions:

1) What is the difference between @Inject and @EJB

2) If I have a simple POJO that contains another POJOs (which one of them is the DAO code), what would be the better choice: @Inject or @EJB?

Can I mix @Inject and @EJB?

An example would be:

• ClassA implements InterfaceA and has an instance of ClassA_Adaptor

• ClassA_Adaptor implements InterfaceAB and has an instance of ClassB

• ClassB implements InterfaceB and has an instance of ClassB_Adaptor and an instance DAO_ClassB

• ClassB_Adaptor implements InterfaceB and has an instance of ClassC

• ClassC implements InterfaceBC and has an instance of WebService_ClassC

• DAO_ClassB will use JPA 2.0 (@PersistenceContext)

I'd like to inject all of them including the DAO and the WebService.

3) Is it a bad approach to only use transactional for certain operations but not for all?

As an example: Some methods in DAO_ClassB are your typical query, while other methods are "write" methods. Is it bad to not wrap the "READ" methods with transaction?

To my understanding, the DAO_ClassB can be wrapped with transaction using @EJB (inject the DAO_ClassB and make all methods transactional). How can I control it?

Sorry if some of the questions are confusing because I know only bits and pieces of the Java EE 6 new component model.

Answer 1

1. @EJB injects EJBs only, but @Inject can be used to inject POJOs rather than EJBs. However, @Inject requires that your archive be a BDA (contain beans.xml for EE 6, or implicitly in EE 7). @Inject also has additional CDI-specific capabilities (scopes, interceptors, etc.), but those capabilities incur extra overhead. Application servers have support for specifying @EJB bindings so that a deployer can choose the target EJB, but @Inject only allows the application developer to choose the target EJB (and it must exist in the application).

2. If the target is not an EJB, then you must not use @EJB.

3. It depends whether you're making multiple inter-related queries and then attempting to make business decisions. You need to understand isolation levels and take them into consideration, even for read-only operations.