This is getting real interesting.
I'm wondering whether the use of Entity Beans is really only useful
if you end up re-accessing the data a number of times. Chris's
description reminds me of the old CICS style programming ie.
program is loaded, accesses database and performs lookup and
updates and then unloaded (with no sense of session state other
than a thing called a commarea which is a couple of K).
If we think in terms of business 'components' we would
split all the business methods and then string them into sequences
which then form a business function. Typically these business methods
might
re-read the same data 'things' over and over (since each method is
independent of each other and hence needs to 're-establish' state).
In this case, if we weren't using data 'objects' but rather raw SQL
calls, we would have the overhead of re-issuing SQL calls against
the same rows in the table. I would have thought that data objects
would optimise this type of access since the first accesses would
result in the loading of the data into memory and then all
subsequent 'getters'/'setter' ('select'/'update')
would access the loaded data, thus saving the re-read/re-update
problem in non object architectures.
If people aren't getting performance out of entity beans, could it be
because the overheads of getting the data only once are putting a
performance overhead that's not required ? If the business function
keeps going back to the entity data I would have thought that there
would be a performance gain (which would be higher the more re-use
of the data there is).
Anamitra, I need to get my confidence back to since entity beans would
be a key to the usefullness of this architecture in scalable apps :-)
Any comments people ?
-
On Fri, 14 Apr 2000 11:38:02 -0700, Chris Raber <[EMAIL PROTECTED]>
wrote:
>Ana,
>
>Your analaysis is correct. I don't know of an application of this
scale
>using Entity Beans. That doesn't mean there isn't one, I just don't
know
>about it! I am not sure how they handle session state in this
application,
>but I think they store sessions in the database, and key them by a
session
>id stored in a cookie or hidden field.
>
>However, I don't think that only using Session Beans mean that EJB
isn't
>providing value. The container is still managin transactions and
security.
>Plus the server/container is providing load balancing, redundancy etc.
You
>have to do more work to each these things using straight CORBA or RMI.
In
>the case of GemStone/J we have additional services of interest too
>(persistent cache...).
>
>IMHO, for systems doing transaction processing, EJB makes sense,
whether
>Entity Beans or not.
>
>Regards,
>
>-Chris.
>
>> -----Original Message-----
>> From: Bhattacharyya, Ana [SMTP:[EMAIL PROTECTED]]
>> Sent: Friday, April 14, 2000 1:28 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Largest EJB Implementation ?
>>
>> Hi Chris
>> It seems to me that their usage of stateless session beans has given
them
>> a
>> such performance --- I really doubt whether they would have got such
>> scaleability if they needed to use stateful session beans/entity
beans.
>> Does
>> it point to the fact that their requirements were pretty simple or
they
>> did
>> some designs like maintaining sessions in the web server and not in
the
>> ejb
>> server??
>> I really dont get what value add I am getting from using EJBs if I
dont go
>> for entit beans or stateful session beans. AFAIK it is not a good
design
>> to
>> make the clients session aware --- and thats precisely why stateful
>> session
>> beans came into being. But then people say it is too slow and go
back to
>> 1> Either storing the session info in HttpSession in the servlets
engine
>> OR
>> 2> Storing session info in a hastable like data structure in the ejb
>> server
>> side -- something like a dependent object to the ejbeans.
>> ie back to square one!
>>
>> And also to me the benefit of using Entity beans comes only when I
go for
>> CMP aproach --- but then also performance issues come and people say
CMP
>> is
>> not developed!!
>> So the result is use stateless session beans --- and my question is
why
>> dont
>> I use simple RMI or CORBA to design my objects???
>>
>> Is there any example of a scalable, working real life implementation
which
>> use EJBs propely?? --- By properly I mean to say the implementation
uses
>> session beans (both stateless and stateful) to represent their
business
>> process and entity beans to represent business logic and business
data.
>> I need this to get back my confidence :)
>> cheers
>> Anamitra
>>
>> -----Original Message-----
>> From: Chris Raber [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, April 14, 2000 1:09 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Largest EJB Implementation ?
>>
>>
>> I don't have tons of data, but here are a few data points:
>>
>> - NetScape WEB servers
>> - Stateless Session Beans
>> - Oracle database
>> - 15 million hits per week
>> - 140,000 users
>> - 150,000 shipments per day
>>
>> Take this with a grain of salt, I am copying it from a mktg
presentation
>> on
>> this account. It gives us an idea of the scale of the thing though.
It's
>> pretty darn big.
>>
>> They run on Sun hardware. Not sure what models, but I believe they
are
>> mid-range servers.
>>
>> -Chris.
>>
>> > -----Original Message-----
>> > From: Jago, Robert [SMTP:[EMAIL PROTECTED]]
>> > Sent: Friday, April 14, 2000 10:53 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: Largest EJB Implementation ?
>> >
>> > Hello Chris.
>> >
>> > Do there exist actual numbers of performance, throughput,
peak
>> > load
>> > numbers for this?
>> > Not to mention infrastructure?
>> >
>> > Rob Jago
>> > Programmer/Designer
>> > Ottawa
>> >
>> >
>> > -----Original Message-----
>> > From: Chris Raber [mailto:[EMAIL PROTECTED]]
>> > Sent: April 14, 2000 10:28 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: Largest EJB Implementation ?
>> >
>> >
>> > <vendor>
>> > Ingram Micro's auction site is built on EJB (GemStone).
>> >
>> > It does zillions of hits per time unit bla bla bla... And the hits
do go
>> > through beans!
>> > </vendor>
>> >
>> > -Chris.
>> >
>> > > -----Original Message-----
>> > > From: Eddie Fung [SMTP:[EMAIL PROTECTED]]
>> > > Sent: Thursday, April 13, 2000 6:27 PM
>> > > To: [EMAIL PROTECTED]
>> > > Subject: Largest EJB Implementation ?
>> > >
>> > > Anyone know what the largest production EJB implementation is
out
>> there
>> > > (subject to non disclosure agreements of course) ?
>> > >
>> > > 'Largest' in terms of a mix of :
>> > > - transaction volume
>> > > - complexity (EJB side, not servlet/client side) ie. 'depth of
logic'
>> > > - database volumes
>> > >
>> > > I'm not interested in apps that have a million hits/minute with
very
>> > > little EJB (or at least simple) activity. That's high TP but not
>> 'deep'.
>> > >
>> > > When you read the literature and the J2EE Blueprint it is always
very
>> > > simplistic and I was interested in the current state of affairs
- EJB
>> > > still being 'bleeding' edge so to speak.
>> > >
>> > > thanks,
>> > >
>> > > Eddie
>> > >
>> > >
>> >
>>
==========================================================================
>> > > =
>> > > 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".
>> >
>> >
>>
==========================================================================
>> > =
>> > 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".
>>
>>
==========================================================================
>> =
>> 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".
===========================================================================
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".
