wrap up multiple entity EJB operations within a session EJB. Ensure that the session EJB begins a transaction that encompasses the entity operations, or has transaction attributes that cause the container to do so.
This is one of the reasons that most authorities recommend the use of session EJBs as a facade to an entity EJB system. Other reasons include the ability to cache entity data in the session EJBs, and the provision of a `coarse-grained' interface to clients.
What does it mean 'coarse-grained' interface to clients.........?
Suppose you have 3 EJBs A, B and C which has methods a(), b() and c() respectively. These methods are fine grained methods and can be reused. However, when you want to expose a business method to the client you want to write a Session Facade pattern [EJB D with method d()] which internally invokes these methods and does some business logic and data manipulation to return a more appropraite object which the client is interested. So your business logic is encapusulated in the business facade and client need not have to write the similar logic in his JSP/Servelt which does't handle transactions. Please read Business Facade pattern for more understading of this pattern and to learn its advantages.
what does it mean: to cache entity data in the session EJBs?
Amit M Tank
Joined: Mar 28, 2004
You might want to have your custom Cache in the Session Bean. But it really doesn't make much sense to cache the Entity data (if the data is not much transactional and doesn't change that often) on the Session Bean side. Most of the appliaction servers like weblogic provides their own Entity Cache.