Hi Dan
I am not sure as to how for example context propagation is possible in the
case that a particular instance of a stateless session bean is accesse
simultaneously by multiple threads. For stateless beans before each method
call the container should call the setSessionContext method of the bean
instance to make it aware of the context. Now the bean developer(ie me) is
suggested to store it the SessionContext in a global variable. So now if
that instance is simultaneusly accesed by multiple threads --- then what
happens to the SessionContext??? --- that context is specific to that
particular clients call!!
Correct me if I am wrong.
Ana
-----Original Message-----
From: Dan OConnor [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 14, 2000 4:20 PM
To: [EMAIL PROTECTED]
Subject: Re: Largest EJB Implementation ?
On 14 Apr 00, at 15:32, Bhattacharyya, Ana wrote:
> 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.
Hi, Ana,
I think it would be possible to do context progogation and
transaction management even if EJB used a single instance/
multiple threads model. I think the reason for the object pool is to
simplify the programming model for the bean developer. He or she
can't maintain state between calls, but CAN have object state while
processing a single call.
Also, I wonder how expensive the pooling model is vs. the single
object/multiple threads model. I suspect that the cost of this
approach is quite low; given a machine with a reasonable amount
of memory, it seems to me that you would be able to serve a lot of
clients with stateless session beans before the difference became
apparent.
Does anyone have any hard data?
-Dan
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".
===========================================================================
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".
