EJB vs. CDI and Entity Boundary Management Template

I am trying to deal with CDI and EJB and Entity Border Management (ECB) pattern. My understanding of the ECB pattern is that the Border is the beginning and end of the transaction border. Additionally, CDI does not provide transaction support like EJB.

So, if I want to successfully implement the ECB pattern, then the following will be true:

  • I can implement the boundary part with EJB (i.e. @stateless, @stateful, @singleton) and the control level with CDI or EJB.
  • I can implement the Boundary and Control part with CDI, but implement Border transaction support similar (http://smokeandice.blogspot.com/2009/12/cdi-and-declarative-transactions.html)
  • I can not implement the border with CDI, and then start using EJB at the management level.

thanks

+6
source share
1 answer

I successfully implement an ECB pattern in JavaEE 6 using EJB exclusively for borders and CDI for controllers. A typical stack in my architecture uses

  • Standless EJB annotated with JAX-RS annotations to implement REST service as boundaries
  • Managed CDI beans for business logic in @Dependent as a controller
  • CDI-managed beans in the @Dependent scope for data access objects that use the JPA EntityManager to interact with the database
  • Jpa beans object

The stateless EJB that forms the border is always annotated with @TransactionAttribute (REQUIRED), which is the default value. I do not use other transaction attributes. Thus, you can guarantee that each interaction with the Border occurs in one transaction.

Using only the @Dependent scope for CDI managed beans, you can make sure that each thread has its own instance of this beans. This way, you have at most one thread accessing a managed CDI bean at a time. This prevents typical concurrency problems.

Using a combination of heavier weights, the combined EJB for the borderline and lightweight CDI-managed beans for the rest of the application is great for me.

+12
source

Source: https://habr.com/ru/post/904217/


All Articles