tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Entity cant be refreshed with new list values
Date Sat, 19 Oct 2013 19:46:29 GMT
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." <smithh032772@gmail.com>
>To: users@tomee.apache.org; Mark Struberg <struberg@yahoo.de> 
>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 <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