Gene,
Sorry, but I think this is not accurate.
If your stateless beans are using some shared resource in the JVM, then that
resource will have to be thread safe. For example if you have a JVM
singleton that many beans are accessing, then access to the singleton would
have to be mutex. Otherwise you risk data tearing, corruption, or in general
having code making bad decisions based on an inconsistent view of things.
And just because a bean is stateless does not mean that it does not have
state. This is a common misconception. The bean cannot have state that is
cached for a particular client, but it can have other state that it uses to
do its job.
Regards,
-Chris.
> -----Original Message-----
> From: Gene Chuang [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, July 17, 2000 6:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Multi-Threaded Protection within a SSB
>
> The container assumes that a Stateless Session Bean is, well, stateless.
> This means that each of the bean's method is stateless, and that the
> member
> variables that the stateless methods use are also stateless. As long as
> you
> abide by this, you should not have to worry about multithreading!
>
> From what you described, your collection of worksteps is stateless.
> Hence
> you should have nothing to worry about!
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Perry Hoekstra
> Sent: Monday, July 17, 2000 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Multi-Threaded Protection within a SSB
>
>
> James Cook wrote:
> >
> > How are your helper methods defined. If they are simply methods in your
> > bean, or classes that are instantiated in your bean, then all is OK.
> >
> > If they are some kind of singleton object in your bean, then you have to
> > handle concurrency.
> >
> > Remember, only one client thread can be in a stateless session bean
> instance
> > at any one time. Matter of fact, the same is true for stateful session
> > beans, and entity beans.
> >
>
> Reading section 6.8:
>
> Because all instances of a stateless session bean are equivalent, the
> container can choose to delegate a
> client-invoked method to any available instance. This means, for
> example, that the Container may delegate
> the requests from the same client within the same transaction to
> different instances, and that the
> Container may interleave requests from multiple transactions to the same
> instance.
>
> What drew my concern was the "the Container may interleave requests from
> multiple transactions to the same instance". If the vendor implements a
> single instance of a SSB (to limit resource overhead) and manages the
> interleaving of requests to that bean, how is access to the shared
> resource (my collection of worksteps) handled.
>
>
> --
> Perry Hoekstra
> Consultant
> Talent Software Solutions
> [EMAIL PROTECTED]
>
> ==========================================================================
> =
> 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".
