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