be careful with immediate=true. You get all sorts of nasty side effects. see page 92 in http://people.apache.org/~struberg/eesummit2013/Java%20EE%20Summit%20-%20pitfalls%20in%20EE.pdf
LieGrue, strub >________________________________ > From: "Howard W. Smith, Jr." <[email protected]> >To: [email protected]; Mark Struberg <[email protected]> >Sent: Saturday, 19 October 2013, 21:40 >Subject: Re: Entity cant be refreshed with new list values > > > >responses inline below... > > > >On Sat, Oct 19, 2013 at 10:49 AM, Mark Struberg <[email protected]> wrote: > >It depends on the application I'd say. >> >>Of course if you use @Stateless then you are really bound to >>entitymanager-per-transaction pattern, and then DTO is almost the only thing >>which really works. >> > > >this is definitely what i'm doing. only @Stateless @EJBs, no @Stateful @EJBs >at all. > > >>If you use @Stateful + a CDI normal scope and UserTransaction, or you use CDI >>+ @Transactional with either UserTransaction or a producer for an >>EntityManager then you can also use the entitymanager-per-request pattern. >>This plays really nice together with mostly CRUD JSF2 apps where the xhtml >>stuff will then be able to lazy-load the data it needs. >> > > >+1 on the entitymanager-per-request-pattern recommendation. Definitely >something that I am not doing, but I think it may work with approach that I've >seen recommended by some of the experts in PrimeFaces forum (@RequestScoped >beans > @EJBs). please correct me if my assumption/association is incorrect. > > >i definitely need to gain some experience using producers and user >transaction, and @Transactional. > > > >>This has a few pros: >> >>* no DTO needed as you can use the entities directly in your backing beans. >>Usually DTOs are mostly 1:1 the data from the entities anyway for those cases. >>* the entity will get automatically detached after the first request, any >>cancel on the postback will not store the state to the DB that way. >> > > ><snip> >* this means that all the JSR-303 BeanValidation annotations from your >entities also work out of the box in your JSF2 app, without having the need to >do all those validations manually and maintaining them twice! >> ></snip> > > >interesting. i am using @Stateless @EJB (+DTO) and my app/pages are using >BeanValidation nicely (when I want the app to do that...usually on save/update >requests/posts). i definitely use immediate=true, when I don't want bean >validation to do it's thing on commandbutton/link posts in/from xhtml pages. > >* Save will be done by simply em.merge the entities. There is no further need >to manually apply any values nor check for any locking as the information is >already available in your JPA entity. >> > > >hmmm, my save/update are definitely using em.merge in @Stateless @EJBs. > > >i have the following in my AbstractFacade class: > > > public void edit(T entity) { > // 2011-09-17 flush immediately after merge > getEntityManager().merge(entity); > getEntityManager().flush(); > } > > >and JSF controller class has the following: > > > getFacade().edit(current); > > >on a page that allows enduser to edit data, I always get a managed entity. > > > > >>But you also need to be aware of a few cons of this approach: >>* if you have an application which takes a few requests to the server to >>render all state, then this will not work. The entity is only in managed mode >>in the first request - all later requests will fail to load not yet touched >>lazy fields. This e.g. makes it impossible to use entitymanager-per-request >>in Vaadin apps (Vaadin is nice from an UI perspective, but wtf, this does >>SOOOO many round trips to the server an almost any click in the UI!) >> > > >interesting, i definitely only want one trip to server on button-click in the >UI. > >* if you have a remoting technology which does transfer 'exact' >representations. Then you need some mapping layer anyway. >> > > ><snip> >* if you are bound to use pure @Stateless EJBs for your services ;) >> ></snip> > > >i think that would be me. :) > > >>In this cases a DTO approach is really better usually. >> > > >agreed. > > > > > >
