Re: Session Bean's for Querying???

[David Wall]

Title: RE: Session Bean's for Querying???

This does seem to be a problem with EJB, but if you don't check the db, you're never sure if the membership info was changed somewhere else. If you don't care or the object is not updated by any other user, you could even cache it yourself, such as in a sevlet/stateful session object for the user.  Just calculate how big the membership info object will be and do the math to see how much you intend to keep cached.  If you end up swapping/thrashing, you'd be much better off getting it from the db.  Most DBs have excellent caching systems. David ----- Original Message ----- From: Shehrawat, Rishi To: [EMAIL PROTECTED] Sent: Monday, May 29, 2000 8:34 AM Subject: Re: Session Bean's for Querying??? the problem with entity beans is that one read would imply 3 db hits, unless the server provides optimisation facilities (weblogic 5.1). One hit when the finder method is invoked, a remote reference object is returned, then the container synchorises the data from the dbase before a method invocation so another hit, & another when the bean is passivated & ejbStore is called.. this works well for transactions but for read only operations it this is a killer.. Yes there are advantages of the bean being in the memory but i think the db hits kills it.. moreover if the bean that is required in the memory then it might save one db operation & yes time is also saved as the pool of entity beans is already there.. but still this will be resource heavy for read oly operations.. This is my understanding.. PLease correct me if i am wrong..