I provided a solution where we started off with entity beans in a case where we
were doing 1) thousands of lookups at a time (read only), and 2) thousands of
inserts at a time.
for
1) when we were using entity beans it would take in the order of 30 minutes of
processing to get out 24 requests of 10000 beans at a time, process them into
data objects and pass them back to the client. We changed the processing from
using entity beans to straight SQL, and the time went down to 10 minutes of
processing. I am not sure what the cache hit rate was for the entities. The
hardware for this was a 4 processor ulra-sparc with 2GB ram.
for
2) when we were inserting the same basic number of beans, we were getting each
bean inserted at 88ms per bean. The database was Oracle, running on an old Sun,
1 processor, 256MB ram. When we changed from creating the entity beans to doing
batch sql inserts. Our insertion rate came down to between 10-15 ms per row.
In both cases we made no other architectural changes other than the ones I
mentioned. In both cases we were using Weblogic 4.0... We are still trying to
figure out what Entity beans are good for, except for one or 2 accesses. If you
are working with bulks of data at one time, entities are probably not a good
idea.
Chris.
Sharat Hegde wrote:
> Most of the EJB books encourage us to use Stateless session beans for
> reusable queries.
> I however have a doubt regarding this.
>
> If I encapsulate my query say in getMemberInfo(String Id) which happens to
> be one of my business methods of a stateless session bean, then I understand
> that every time a client comes to my site and wants to view his info then my
> session bean is going to make a DB hit. Assuming that my site receives
> 100000 hits per second or say atleast 100 hits per second then each time my
> session bean will have to hit the DB. And hitting the DB and returning the
> resultset involves time and also chews up resources. Isn't it?
> So knowing all this do I still have to go for session beans? I also assume
> that i am using connection pool for picking up DB connections.
>
> If I use my entity bean with a findbyMemberId(String Id) then probably I
> would reduce this overhead, because the entity's memory will be loaded with
> that particular record. So next time the same user comes then I will not
> have to hit the DB ( of course I am assuming that the entity bean is still
> present in the server.)
>
> Please give me more insights from ur experience and understanding..
>
> Thanks
>
> > Love
> > Gp
> > Extn:3471
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
