Agreed, straight CORBA is leaner. It's also a bit more system architecture
work. For the less experienced developer, EJB provides a simpler conceptual
model. In any event we can do it both the CORBA and the EJB way in GS/J!
Have your cake and eat it too?
Regards,
-Chris.
> -----Original Message-----
> From: Bhattacharyya, Ana [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, April 14, 2000 3:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Largest EJB Implementation ?
>
> 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".
===========================================================================
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".
