CODEWITHSUNDEEP
jpaejb-3.0lazy-loadingeclipselink
illEatYourPuppies
illEatYourPuppies

Reputation: 611

JPA lazy loading strategies for remote client using EclipseLink

1. Question

What are known strategyies, solutions for LAZY-loading from client side? I was checking out this stuff http://wiki.eclipse.org/Introduction_to_EclipseLink_Sessions_(ELUG)#Remote_Sessions but not sure if this is a solution to my problem or how to use this.

2. Use-case

I'm developing a three tier application where my presentation layer (Eclipse RCP) is a remote client over network:

[ Eclipse RCP ] <-----(RMI)-----> [ [EJB 3] [JPA 2] [Mysql] ]

Now, I use JPA Entities as my domain model which I want to use in my client as well. I get the entites from @Session beans over network. Problem happens when my JPA Entites have LAZY fields. After serialization and especially because my JPA provider (EclipseLink) is over the other side of the network I need a strategy to load those LAZY fields from client.

I'm going to have many entities: 30-40 maybe. And typical scenario would be when the user sees a list of SomethingModel which has many List fields, but those are not needed to be shown on the list, only when she want's to change a specific element.

3. Possible Solution

I came up with one solution e.g.: I create proxy classes for my JPA entites in client side. When I need a collection field from my Domain model, the proxy class will call the remote EJB to populate the field.

class CarModelClient {
  CarModel model;

  public String getColor(){
    model.getColor();
  }

  public List<Wheels> getWheels(){
    CarModelFacadeRemote carFacade = //get my remote ejb
    model.setWheels( carFacade.getWheels( model.getId() ) );
    return model.getWheels();
  }

}

Well, similar to that.

Thank you for your answers.

Upvotes: 3

Views: 2815

Answers (1)

JB Nizet
JB Nizet

Reputation: 691625

Don't try to be too smart and pretend like the client was on the server, and the entity manager was always open. Consider the domain objects, at client-side, exactly as you would consider DTOs or JSON objects: objects containing some information coming from the server and seralized over the wire.

Document the service methods called from the client (the facade methods) to specify which associations are initialized and which are not in the returned entities. If you are on some "list" screen and want to see the detailed view of one of the elements of the list, for example, call another service which loads the entity again from the database (and thus gets fresh results), with probably other associations initialized in order to display more details about the entity.

Trying to dynamically initialize the lazy-loaded associations at the client just doesn't work: it's complex, inefficient, results in an obsolete and incoherent graph on the client, doesn't take transactional isolation into account.

Upvotes: 1

Related Questions