tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Entity cant be refreshed with new list values
Date Sat, 19 Oct 2013 12:49:11 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message