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 14:49:35 GMT
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.

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. 

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

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

In this cases a DTO approach is really better usually.

LieGrue,
strub




----- Original Message -----
> From: Romain Manni-Bucau <rmannibucau@gmail.com>
> To: users@tomee.apache.org
> Cc: 
> Sent: Saturday, 19 October 2013, 14:49
> Subject: Re: Entity cant be refreshed with new list values
> 
> More i work on apps more i think jpa should be hidden of business
> code...just my opinion. Technically both works
> Le 19 oct. 2013 14:07, "Howard W. Smith, Jr." 
> <smithh032772@gmail.com> a
> écrit :
> 
> 
>>  wow, interesting response, (thanks) Mark! responses inline..
>> 
>> 
>>  On Sat, Oct 19, 2013 at 3:16 AM, Mark Struberg <struberg@yahoo.de> 
> wrote:
>> 
>>  > Much easier solution:
>>  > mark the fields you don't like to persist as
>>  > @javax.persistence.Transient
>>  >
>> 
>>  interesting, did not know this.
>> 
>> 
>>  >
>>  > In standard EJBs you will get the entitymanager-per-transaction 
> pattern.
>>  > Which means that any lazy loading field or relation you did not touch 
> in
>>  > your EJB will remain null forever.
>>  >
>> 
>>  i learned this after some time and work'ed around this by populating
>>  lists/collections in 'other layer of app' after the EJB retrieved 
> the
>>  @Entity, where populating = use multiple other/corresponding EJBs to
>>  populate each related List/Collection of @Entity. Bad design/performance,
>>  I'm sure.
>> 
>>  'did not touch'? i think you are referring to checking size() or 
> isEmpty()
>>  on Lists/collections that belong/related to @Entity... before @Entity is
>>  returned from @EJB method. I think I read somewhere how size() and
>>  isEmpty() will retrieve the data, but now I know, you must do this inside
>>  @EJB. right?
>> 
>> 
>>  > If you are aware of this restriction, then all is fine and you can use
>>  > EJBs. Nowadays a DTO is nothing more than making sure that you touch 
> all
>>  > the fields an info you need in the other layer of your app,
>>  >
>> 
>>  It is interesting that you refer to it as a restriction. do you
>>  prefer/recommend this approach, or another approach? I will have to see if
>>  I can improve my app a bit by keeping this in mind (as I have bandwidth to
>>  do so). thanks.
>> 
>> 
>>  > Btw, you should add a
>>  >
>>  > @Version
>>  > private Integer optlock;
>>  >
>>  > to all your entities. Otherwise you will not have any locking in the
>>  > database. And of course if you use DTOs then you will also need to set
>>  this
>>  > info into your DTO and do a manual comparison in your EJBs to make 
> sure
>>  the
>>  > entitiy did not get changed in the meantime.
>>  >
>> 
>>  are you recommending this for only OpenJPA users? I'm using EclipseLink 
> and
>>  (Apache) Derby. I think I read about this before somewhere; is the
>>  'optlock' part of Java EE implementation or just for OpenJPA users?
>> 
> 

Mime
View raw message