Hi Satya,
The *fix * you mentioned is incorporated - in a way - by EJB2.0
specification. It allows entity bean to have home business methods in the
entity beans home interface.
Regards,
Hemant
Server Team,
Pramati Technologies
www.pramati.com
----- Original Message -----
From: "Komatineni, Satya" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 08, 2001 11:25 PM
Subject: Re: Why can't a "stateless session bean (slsb)" be single instanc
e?
Gene,
When it maintains state within a single invocation, what happens when the
session bean is returned to the pool? Does some one cleans up the state to
it's original so that when it is handed over to the next client, the
previous state is not kept (I call it dirty state)?
If the container cleans up the state between method calls, I can understand
that you can kind of use the internal state between internal method calls.
But if the container doesn't clean up then the burden to clean up the state
is upto the individual bean. Although imaginable, just round about fix for
writing your methods stateless to begin with.
Thanks
Satya
-----Original Message-----
From: Gene Chuang [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 1:15 PM
To: [EMAIL PROTECTED]
Subject: Re: Why can't a "stateless session bean (slsb)" be single
instanc e?
There is a common belief that a Stateless Session Bean cannot maintain
state. This is NOT true. According to specs, a SLSB cannot mantain state
BETWEEN two client invocations; however it can maintain state within a
single invocation (i.e. hold reference to stateful info that is used
throughout a single SLSB method call). Hence this should answer your
question why vendors should NOT implement SLSB as singletons!
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Komatineni, Satya
Sent: Tuesday, May 08, 2001 5:14 AM
To: [EMAIL PROTECTED]
Subject: Why can't a "stateless session bean (slsb)" be single instance?
In an SLSB, each method is independent of the other methods. There is also
an implied understanding that a method should not update the state of the
object becasue the next scheduled method is not guranteed to get that
updated state. And I haven't seen in the spec that when a method scheduled
for an SLSB it's internal state is going to be initialized to the original
state (in other words the create method being called). Which means one can
have dirty data in SLSB if a mehtod (local or remote) happens to update the
state. As a result, it is reasonable to assume that, no method should update
the internal of an SLSB. That also means that we will have only read-only
private variables.
If that is the case, why can't the EJB container simply allow multiple
threads call into the same SLSB all the time, saving lots of object
creations. There is also this restriction that at any given time, only one
thread is allowed in a bean. Does this restriction really make sense here? I
am sure you can still apply transactional gurantees with out this
restriction.
Can someone comment on this?
Thanks
Satya.
===========================================================================
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".
===========================================================================
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".
