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".
>
__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com
===========================================================================
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".
