Hi All:
I think we should consider the basic way how Stateless Session beans work. Sessions beans provide method level isolation. It totally depends on the App Server how it uses the pooling mechanism and all other stuff. Thus the same bean can be used to serve two different clients, perhaps this is the point which ws missed. It is always recommended that you should not maintain state in your Statleless Session Beans by defining some variables which are dependent on clients sessions, and also with this the basic essence of SSB is not maintained.
Cheers,
Sourabh
-----Original Message-----
From: Aggrawal, Shelly (Cognizant) [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 02, 2001 12:19 PM
To: [EMAIL PROTECTED]
Subject: Re: State in stateless session bean
In my opinion also, the stmt "no conversational state" can be misleading if
interpreted as "conversational state being wiped out for each call"
A question to guru's, could there be some other reason why SUN has used the
stme "no conversational state" rather than "not guanranteed".
-----Original Message-----
From: Gavin Selvaratnam [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 02, 2001 12:07 PM
To: [EMAIL PROTECTED]
Subject: Re: State in stateless session bean
Hi,
Thats just the case. Going through the EJB specifications I just
couldnt get it that whats is ment when they say "Stateless session beans
are session beans whose instances have no conversational state.". What I
thought was that state is irased for each method invocation. But In the
specification it doesnt tell you anywhere that "State is not garantied".
Dont you think Sun should say those exat words when they describe
stateless session beens ? I got to think about this only after doing a
sample.
Thanks,
Gavin
===========================================================================
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".
