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".
