BMP Entity Beans

Discussions

EJB design: BMP Entity Beans

  1. BMP Entity Beans (7 messages)

    How do I prevent calling of ejbLoad method for every get Method call on an Entity EJB?

    Threaded Messages (7)

  2. BMP Entity Beans[ Go to top ]

    Use the Session Facade Pattern, DTO (Data Transfer Objects) and transactions.

    In particular, never directly invoke your Entity Bean from your client. Instead, write a Session Bean to retrieve Entity Data, and store in another, normal Java object (the DTO).

    Finally, make the session bean method that assembles your data is transactional (transaction attribute "Required").

    The reason why this will work is that most EJB servers are optimized so that they invoke the ejbLoad() method exactly once within a transaction. If, on the other hand, you invoke the getter methods directly from your client, you will have one transaction per getter method, and therefore one call to ejbLoad() per getter method.

    For a longer discussion of the Session Facade and DTO patterns, go:

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html

    and

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
  3. Where to define the TransferObjects[ Go to top ]

    I was reading the patterns that you mentioned and (being new), have a question or two.

    If the TransferObject is created by the EJB and sent to the Client. . .

    The TransferObject needs to be defined in the EJB package if the EJB is going to use it *and* in the Client package for the client to know what the class looks like, right? So I have an identical class that must be kept identical in two packages. This way the EJB can be deployed to one computer and the Client code to another machine.

    If I only define the TransferObject in one package, then I create a cycle between the client and EJB package. They must be deployed together to the same machine.

    The only other option I see is to define a third package to contain TransferObjects and have the EJB and Client package both reference it.

    Am I missing something, or is one of the above common practice (if so. . .which!). Thanks!
  4. Where to define the TransferObjects[ Go to top ]

    It does not matter so much which Java package you put your Transfer Objects in. Most people tend to put them in the EJB package.

    What really matters is what JAR file contains your Transfer Object classes. Again, most people put them in the EJB JAR.

    When you deploy your EJBs to the EJB server, the server will create a client-jar, which you must then install in your EJB client. This client JAR will contain the remote and home interfaces of your EJBs, the server-generated stubs allowing the client to remotely communication with your EJBs and all the other utility classes in your EJB jar. This will include your Transfer Object classes.

    To sum up: put the Transfer Objects in your EJB package/jar, and they will be distributed to your client in the server-generated client JAR.
  5. Where to define the TransferObjects[ Go to top ]

    Ok, so the TransferObjects should also have Remote and Home interfaces? Please say yes. . .that would make sense to me. ;)
  6. duh[ Go to top ]

    Nevermind. I've been playing with this stuff today and I think I understand your post better now.

    At *deployment time*, the person responsible for deploying the EJB's needs to be certain to copy the client code created by the server to the appropriate location. That is, to the machine(s) that have the Web stuff (Servlets, JSP's, etc).

    I didn't realize that at deployment, utility classes and Transfer Objects (and whatever else besides EJB's) are placed in a client jar. Two questions. . .
    1) Has this always been the case in the J2EE specs (that a client jar would be generated from deploying the EJB project)?
    2) How does the server *know* what should be in the client jar? Simply checking if it extends EntityBean et.al?

    Thanks!

    From your post. . .
    ". . .and all the other utility classes in your EJB jar. This will include your Transfer Object classes.

    To sum up: put the Transfer Objects in your EJB package/jar, and they will be distributed to your client in the server-generated client JAR."
  7. duh[ Go to top ]

    I didn't realize that at deployment, utility classes and Transfer Objects (and whatever else besides EJB's) are placed in a client jar. Two questions. . .

    > 1) Has this always been the case in the J2EE specs (that a client jar would be generated from deploying the EJB project)?
    > 2) How does the server *know* what should be in the client jar? Simply checking if it extends EntityBean et.al?

    To be honest, the specs are kind of vague about what goes into the client jar. In practice, every EJB server I have worked with puts everything that was in the EJB jar into the client jar as well (with the possible exception of the EJB class).
  8. BMP Entity Beans[ Go to top ]

    Depending on the App Server you are using, you have to configure it so that commit option A is chosen. This tells you App Server that it has exclusive access to the data and it will not load data for each get