Session Beans Vs finder Methods?


EJB design: Session Beans Vs finder Methods?

  1. Session Beans Vs finder Methods? (4 messages)

    We have a requirement where in we need to pick up data from more than 1 table for Reporting.

    I would like to know if it would be advisible to go in for nesting finder-methods for each of the tables(Entity-beans) and refine the data in a session-bean using 'if' conditions
    Directly connect to the database from a session bean using a pool-connection?

  2. Session Beans Vs finder Methods?[ Go to top ]

    re: We have a requirement where in we need to pick up data from more than 1 table for Reporting.

    My advice? Use stateless session beans with hand-coded SQL and use your WAS connection pooling.

    You don't need the concurrent update co-ordination that Entity beans provide - and all the associated overhead - for simple reporting. We do all this type of stuff in stateless session beans and they are fast, simple to code, and scalable. Just remember to get the 'lookups' out of the way once and early, as this operation takes the most time - so consider saving a handle(s) to your reporting beans if you are going to call them often.

    Also look at keeping your SQL statically declared and use prepared statements. I've found that using all the above I can run 10's of these report calls per second per client against our Oracle8i databases on very modest hardware (NT with IBM WebSphere).

    Steve Phelan.

  3. Session Beans Vs finder Methods?[ Go to top ]

    Thanks Steve,

    a)What would you suggest if the data picked up from multiple tables needs to be modified? Would you still go in for stateless Session Beans?

    b)Do you think it would be faster to use finder methods of Entity Beans than a session bean, especially when there are a lot of requests from clients (scalability) ?

    Ram Cherote
  4. A question about cached data.

    You mention that you should save the handle to a stateless session bean used for listing behaviour (I'm assuming you only want to do this for data that doesn't change often). Where exactly do you save the handle? Plus, since you aren't guaranteed that you will get the same stateless session bean each time you call it (that is, they do not preserve client state), why save the handle at all? It seems that you may get a different copy of the bean that doesn't contain the hashed data, or perhaps even contains a different set of cached data (if data had been added or removed before the second call). Or am I misunderstanding handles, and they really point to an actual bean instance instead of the EJBObject that usually gets the bean for you?

  5. Hi Jake,

      I guess steve ment saving Home.