deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From titou10 titou10 <>
Subject Re: Extended EntityManager
Date Tue, 21 Apr 2015 14:59:17 GMT
I totally agree with Rafael, you can't say that the EJB model is
broken because you don't use it the right way it is supposed to be

As for other frameworks, they are rules and the ones around the EJB
paradigm they are not so bad IMHO

Your example is simplistic IMHO, in real life you'll want to catch the
exception and react to it, e.g. by displaying a nice message to the
end user instead of letting the container generic exception handler to
take care of it, and decide to rollback or not the transaction (or
take other actions). Maybe is is a problem for you because your
backing beans are not EJB, but servlets that do not control the

In our apps, we are EJB3 and CDI all the way and it works very well.
Basically we have 3 layers:

- backing beans (aka "View Controllers"), mostly SFSB, in ViewScoped
or ConversationScoped), exposed to JSF. Usually

- "managers", that implements business logic, handles access to the
database etc (Always SLSB, not exposed to JSF, only called from "View

- Entities (JPA, Hibernate), detached, may be directly exposed to JSF.
No need for DTO or so called transport objects..

- the EM is held in the Conversation scoped and exposed in the
RequestScoped as explained before, transactions are managed by the
EJB3 Containers, no need for extra filters etc.

View Controllers react to user actions, manage navigation, call
managers for business logic, catch exceptions raised from them, and
usually in this case call "setRollbackOnly" and display a nice message
to the end-user.

As a  "security net", the "global container exception handler"
performs a transaction rollback in case an exception comes up there
with a still active transaction before displaying a "generic error
page". "em.flush()" is called judiciously in the view Controller to
catch potential db exceptions before letting the container commit at
the end of the initial method called.

We already talks about this months ago in some forum. It is your right
to claim that the EJB paradigm is broken (and you clearly have the
authority/experience/legitimity etc to do it.), but as Rafael said, it
strangely works very well for many many applications when you follow
the way it is meant to be, including  us, and for many other people
that use it also.

Previously, the (your) arguments against our architecture, was that a
lot of (useless) transactions are started on each page because of the
calls to the SFSB View Controller (eg getters). But what we've seen in
real life, at least in WebSphere v8.5, is that this is negligible as
the Container seems to be optimized to do the costly job around
transactions only when a resource manager (the EM) is really "used"
during the request

This architecture also gives a "clear straight path" from Seam 2/JSF
1.2 to CDI/JSF2.0, but I understand that people may want to move away
from it.

Clearly, there are two schools here, one with EJB and one without.
Both have advantages and drawbacks IMHO..and there is not just one way

Seam 2 attracted us because it simplified things and simplified code
layers, and we continue to use the same paradigm with CDI now, JSF
2.0, and  EJB3, as in Seam 2. Very fast to develop, easy to understand
and maintain, no proprietary framework in the way, no performance
problem or other problems.

On another subject, thanks for your blog Mark, which is always
interesting to read.

Cheers, choice is fun!


(Please view this post as way to bring another constructive brick to
the discussion and not for anything else)

2015-04-21 7:07 GMT-04:00 Rafael Pestano <>:
> Hi Mark,
> i don't think it's broken but i agree with CODI/DS transaction management
> superiority, in fact i've using it for years on my personal projects
> <>
> but use EJBs on my company and don't think its broken, even for high load
> application.
> Congrats for the post.

View raw message