tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <>
Subject Re: Entity cant be refreshed with new list values
Date Sat, 19 Oct 2013 19:40:56 GMT
responses inline below...

On Sat, Oct 19, 2013 at 10:49 AM, Mark Struberg <> 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.


> * 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!

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

and JSF controller class has the following:


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.


> * if you are bound to use pure @Stateless EJBs for your services ;)

i think that would be me. :)

> In this cases a DTO approach is really better usually.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message