Discussions

EJB design: session/entity beans and persistence

  1. session/entity beans and persistence (1 messages)

    Hi;

    Ok, for the normal Session Facade pattern (servlet accesses remote stateful session bean that access local entity bean), what are the opinions on:

    1) Keeping the session bean in the servlet. Or keeping the home in the servlet and doing a create(pk) each time. Or keeping the pk and doing both a home lookup and create each time. (By each time, I mean each time the servlet is called.)

    2) Do you need to call bean.remove() HttpSessionBindingListener.valueUnbound() (reading the spec seems to say yes - but every example I have ever seen doesn't bother).

    3) Keeping the entity bean in the session bean and reloading it on setSessionContext. Or keeping the entity home in the session bean and doing a findByPrimaryKey (pk) each time. Or keeping just the pk and looking up the home and then doing a findByPrimaryPk each time. (By each time I mean each time a business method is called.

    4) Use stateless session beans and each time the servlet needs to do something, it creates the session bean and then the business method loads the entity bean, does it's thing, returns, and the session bean is then done. (As a stateless one, there is definitely no need to do a remove.)

    Comments?

    thanks - dave
  2. session/entity beans and persistence[ Go to top ]

    My preferences:

    1) Cache the Home Interface, but not the Remote Interface. I am paranoid that EJB stubs may not be thread-safe, so I always look up the Remote Interface each time. This only makes sense, though, if you are using a Stateless rather than Stateful Session bean. If you are using a Stateful bean, cache it in the servlet session (I would not recommend this, though).
     
    2) Do you need to call bean.remove() HttpSessionBindingListener.valueUnbound() (reading the spec seems to say yes - but every example I have ever seen doesn't bother): Calling remove() does not hurt, so go ahead. If you are using Stateless beans, though, it generally does not matter.

    3) If you are using Stateful session beans, cache the remote interface, but with a Stateless session bean, only cache the Home interface.
     
    4) Always use Stateless beans over Stateful beans when you can. Your performance will always be better. If you need to cache application data, do it in the Servlet session, then pass this data as instance variables to your Stateless Session bean methods.