tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
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 <struberg@yahoo.de> 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.

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