I think where a member is to be lazy loaded this can be achieved is the EMF is smart enough. As a basic outline, the enhancement of an entity includes a mechanism to handle the remote calls of lazily loaded members. If I locally access a member that is lazily loaded, the enhancement them initiates the remote call.
I think a remote interface is the way to go, it will allow for a multi-vm lazy loading, the structure of which could later be determined. One could argue that in this case we haven't gained much over EJB 2.0, but that is my basic point in the first place:) Chris -----Original Message----- From: Trenton D. Adams [mailto:[email protected]] Sent: Monday, 31 May 2010 2:37 PM To: [email protected] Cc: Trenton D. Adams; [email protected] Subject: Re: equals, hashcode, toString, etc, and field access Okay, some thoughts about your suggestion. When the object gets returned by a method call, to be serialized across the network, how will the entity manager be in control of that object anymore, to make sure the needed items are lazily loaded? I suppose it could implement the serializable methods, and load everything when they are called by the system. But, if it did that, it may be loading more than what is really needed. Say I have a student object that holds all the information about the student, including courses, demographics, grades, etc. Wouldn't that be a bit heavy on the network link? Unless we can answer a question like that, I would rather see, at least in terms of EJB, a remote-able entity. Perhaps one solution could be to pass the system a map (not java.util.Map necessarily) of what part of the object needs to be fully loaded before being serialized across the network link? Anyhow, your suggestion would totally work in a single VM, where you use enhancement. ----- "C N Davies" <[email protected]> wrote: > From: "C N Davies" <[email protected]> > To: "Trenton D. Adams" <[email protected]>, [email protected] > Sent: Sunday, May 30, 2010 11:22:18 PM GMT -07:00 US/Canada Mountain > Subject: RE: equals, hashcode, toString, etc, and field access > > EntityManagerFactory. > > > -----Original Message----- > From: Trenton D. Adams [mailto:[email protected]] > Sent: Monday, 31 May 2010 2:19 PM > To: [email protected]; [email protected] > Subject: Re: equals, hashcode, toString, etc, and field access > > EMF? > ElectorMagnetic Field? > English Musical Festival? > Educational Media Foundation? > Energy Modeling Forum? > Eclipse Modeling Framework? > > Google wasn't helpful. lol > > ----- "C N Davies" <[email protected]> wrote: > > > From: "C N Davies" <[email protected]> > > To: [email protected] > > Sent: Sunday, May 30, 2010 7:14:44 PM GMT -07:00 US/Canada Mountain > > Subject: RE: equals, hashcode, toString, etc, and field access > > > > I know others share my feelings because many have articulated the > very > > same > > thoughts to me on numerous occasions, the attached/dettached state > > complicates the whole JPA process. Having worked with a couple of > > commercial persistence APIs for a number of years, I don't really > see > > the > > need for it. > > > > Why we have to open and close a entity service repeatedly doesn't > make > > any > > sense to me, if we want back to using basic JDBC calls we'd just > > open > > connection or create a connection pool at application start and > close > > it at > > exist. The actual connection management should be transparent to > the > > user > > once the connection pool has been established. Instead we now have > to > > worry > > about creating an entity manager and working out if the entity is > > attached > > or detached. If you take a look at the list archives you will see > that > > it is > > a significant issue for many people. > > > > What I would envision is a static multithreaded EMF with no need > for > > an > > entity manager that automatically manages attached and detached > state, > > you > > still get lazy loading because the EMF is smart enough to lazy load > > unless > > the user accesses the lazy loaded field. The EMF would then persist > or > > merge > > automatically depending on whether the entity is new or dirty. > > Building > > these smarts into the EMF would make things much easier especially > for > > new > > users and frankly would make the code a whole lost tidier. > > > > Chris > > > > -----Original Message----- > > From: Craig L Russell [mailto:[email protected]] > > Sent: Sunday, 30 May 2010 5:12 PM > > To: [email protected] > > Subject: Re: equals, hashcode, toString, etc, and field access > > > > I'm interested in hearing what you would like to see with regard to > > > entities after the persistence context in which they were valid no > > > longer exists. > > > > Thanks, > > > > Craig > > > > On May 28, 2010, at 7:18 AM, C N Davies wrote: > > > > > Darryl is right, I fought with this one for some time then it > dawned > > > > > upon me > > > that I was dealing with a detached entity that had a lazy loaded > > > > field. The > > > result of toString is like picking the lottery numbers.. pot luck! > > > > > > Now do > > > the same thing with runtime enhancement during development and > > > deploy it > > > with build time enhancement. > > > > > > Yet another reason to drag the JPA spec into the 20th century and > do > > > > > away > > > with this whole attached / detached state business. > > > > > > Chris > > > > > > > > > > > > -----Original Message----- > > > From: Daryl Stultz [mailto:[email protected]] > > > Sent: Friday, 28 May 2010 10:23 PM > > > To: [email protected] > > > Subject: Re: equals, hashcode, toString, etc, and field access > > > > > > On Thu, May 27, 2010 at 8:49 PM, Trenton D. Adams > > > <[email protected]>wrote: > > > > > >> > > >> I mean I know if I'm doing lazy loading, toString won't get all > the > > > > >> data, > > >> cause it hasn't been enhanced. > > > > > > > > > Assuming the object is detached, yes. I believe the JPA spec does > > not > > > specify the behavior for attempted access of an unloaded property > on > > a > > > detached entity. I believe OpenJPA returns null. This makes it > very > > > difficult to tell if an association is null or not loaded. I have > > > > configured > > > OpenJPA to disallow access to unloaded properties of detached > > > entities to > > > avoid the confusion. This means a toString method like yours in my > > > > > > project > > > could crash. > > > > > > -- > > > Daryl Stultz > > > _____________________________________ > > > 6 Degrees Software and Consulting, Inc. > > > http://www.6degrees.com > > > http://www.opentempo.com > > > mailto:[email protected] > > > > > > > Craig L Russell > > Architect, Oracle > > http://db.apache.org/jdo > > 408 276-5638 mailto:[email protected] > > P.S. A good JDO? O, Gasp!
