Hi,
This boils down to the fact that some application servers started out as web
application servers and then turned into ejb application servers while still
keeping their legacy architecture. Net Dynamics is an example of this. I
used NetDyanmics many years ago and at the time is was a good solution. But
that was then. Now when people are looking for a EJB Server they should
consider only ones that where built from the ground up for EJB 1.1 and based
on a mature and proven infrastructure such as CORBA.
William
> -----Original Message-----
> From: Jose Gonzalez [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, March 10, 2000 10:40 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Concurrency in stateless session beans
>
> The problem in my case is that NetDynamics seems to impose this kind
> of
> singleton pool in a per session basis. What does this mean? See below...
>
> Scenario 1. I have one Java program with several threads. Each of the
> threads makes something like this:
> Bean bean = home.create( ); // bean is an stateless session bean
> bean.method( ); // method contains log messages in its beggining,
> middle and end
> In this case I obtain sequential execution of the method calls, as it
> can
> be seen from the NetDynamics log.
>
> Scenario 2. I have several Java programs like the one above. In this
> case I
> obtain concurrency among programs, but not among threads inside a program.
>
> If I add that I have obtained some exceptions for timeouted sessions
> (?!?!?!) if my program doesn't call the ejb in a long time, we have the
> whole
> picture...
>
> I think NetDynamics assigns a session to any external client
> connecting to
> ejbs (?!?!?!) and that only one instance of an ejb associated to this
> session
> receives all the requests made from that external client. Anyone has
> experienced this? Any NetDynamics (from Sun) engineer/programmer can
> confirm
> this?? Is this a serious ejb implementation?
>
> Regards
> Jose
>
>
> Rickard �berg wrote:
>
> > > I think the container decides whether to maintain the
> > >pool of objects for a stateless bean or to serialize
> > >access to the bean.
> > >
> > > Vendors, any comments on how it is implemented? In
> > >fact, does the deployer have an option to configure
> > >that?
> >
> > I am the container developer for the next version of EJBoss
> > (www.ejboss.org). In our deployment tools you can choose which kind of
> > pool implementation you want to use (you can also choose caching type,
> > distribution protocol and persistence manager through the deployment
> > tool, but that was not the question). One special kind of pool that we
> > have, which you would want to use for stateless session beans, is the
> > "Singleton pool". This pool only maintains one instance, making it
> > possible to use session beans for singleton-type functionality, yet
> > still having all the benefits of EJB (tx's, security, etc.). Very
> > useful. :-)
> >
> > Note: this functionality is not yet available, but will be in the next
> > major version. Please come to our session at the O'Reilly conference (in
> > Santa Clara, March 27-30, http://conferences.oreilly.com/java/) if
> > you're interested.
> >
> > /Rickard
> >
> > --
> > Rickard �berg
> >
> > @home: +46 13 177937
> > Email: [EMAIL PROTECTED]
> > http://www.dreambean.com
> > Question reality
> >
> >
> ==========================================================================
> =
> > 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
