Along with 7.11.8, I think the passivation and coversational state sections
are relavent.
My understanding of 7.11.8: Non-reentrant instances, is that the EJB
container must only allow one thread to access a session bean at a time. So
if two threads try to access a stateless session bean the container can
either: throw an exception to one of the threads, serialize the requests and
handle them one at a time, or spawn another bean to handle the second
request. Specifically, a session bean cannot make a call to an object that
makes a call back to the orginal session bean--then the thread would be
reentering the bean which would be illegal.
Since the session bean container can only allow one thread in at a time, the
member variable would be thread safe.
I agree that that code is simplistic though. A lot of things can go wrong
with member variables. If the state is not reset, it can cause unexpected
results. Also, member variables must be able to be passivated as per 7.4.1:
Instance passivation and conversational state. So if you have a DataSource
or a reference to a remote EJB, it may have been passivated since your last
call.
If you have member variables, you must make sure that your passivation and
remove methods clean up any resources you may have aquired for the bean and
that your activation method properly resets passivated resources.
Thanks for your help,
Lucas
-----Original Message-----
From: Dan Christopherson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:32 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Stateless session beans
The section germain to the original question is 7.11.8 (2.0 spec)
"Non-reentrant instances"
The container must ensure that only one thread can be executing
an instance at any time.
As far as a stateless bean having member variables, you are correct in
that it isn't prohibited so long as the member variables don't hold
conversational state.
The example code is a bit contrived for simplicities sake. More typical
things to keep as members might be DataSource objects (please, not
Connection objects), the Home of another EJB, etc. Basically, things
that carry some initialization burden but aren't dependent on any
particular client.
-danch
Lucas McGregor wrote:
> I thought that the spec didn't allow this either, but I couldn't find any
> section saying such. Unless this is part of the conversational state as
> defined by section 7.4. But the example doesn't use the variable to
> communicate between method calls, nor is it static.
>
> BUt it still doesn't seem correct to me. Would you be so kind as to point
> out the parts of teh EJB spec I should review.
>
> Thanks for time,
> Lucas
>
>
>
> -----Original Message-----
> From: Rajeshwar Rao V [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 27, 2003 7:23 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-user] Stateless session beans
>
>
> No. As per EJB spec..
> But Yes,ur code _may_ work fine with JBoss.
> Is Jboss not following EJB spec?
>
> -----Original Message-----
> From: Eric Jain [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 27, 2003 10:45 PM
> To: jboss-user
> Subject: [JBoss-user] Stateless session beans
>
>
> Are stateless session beans threadsafe, i.e does the following code behave
> as expected?
>
> public class TestBean
> implements SessionBean
> {
> private int tmp;
>
> // should always return true
> public boolean f()
> {
> tmp = 1;
> boolean b = tmp == 1;
> tmp = 0;
> return b;
> }
> }
>
>
> --
> Eric Jain
>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
