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 used.
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 transaction. 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 Controllers") - 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! Denis (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 <[email protected]>: > 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 > <https://github.com/rmpestano/jsf-issuetracker-project/blob/master/src/br/com/triadworks/issuetracker/dao/impl/IssueDaoImpl.java> > but use EJBs on my company and don't think its broken, even for high load > application. > > Congrats for the post.
