yeah Chris --- u are right that it gives the distributed transaction
management --- which I dont get in RMI/CORBA. But not without a cost.
Just consider the fact of stateless beans/objects --- In case of RMI/CORBA
the system will maintain a single instance of that object and multiple
threads can access that object simultaneusly --- no object pool need to be
maintained -- as the object is stateless --- but compare it with EJB
stateless session beans --- there a pool of them also needs to be maintained
as a particular instance of that object can be accessed by only one thread
at a time and the reason is this context propagation and transaction
management. I definitely think the model which RMI/CORBA uses is better
performant. In fact this is the same model which the servlet engine uses for
managing its servlets which does not implement the SingleThreadModel.
But ofcourse I agree for systems which need transaction mangement and
connection pooling --- ejb is must.
regds
Anamitra
-----Original Message-----
From: Chris Raber [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 14, 2000 2:38 PM
To: [EMAIL PROTECTED]
Subject: Re: Largest EJB Implementation ?
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".
