Question About Statefull Vs. Stateless Session Beans

[Former Member]

Hi,

I'm fairly new to the web application server, and have the following scenario and question relating to stateless vs. statefull session beans.

Let's say I have a bean that offers some kind of service and the bean accesses database(s) as part of fulfilling that service. If the bean maintains a single private 'connection' variable to access a database, it seems to me that the bean would be vulnerable when there are multiple concurrent clients. So if client A is being given results, but client B comes along and asks for a new connection, things may get messed up with client A.

Will implementing the bean as a statefull session bean prevent the messed-up scenario described in the previous paragraph? In other words, will the bean have the necessary concurrency management support if it's implemented as a stateful session bean? Or would you be better off to go with a stateless session bean and implement your own connection pooling management? I would like to think "no", and I would imagine that the scenario described here would be one of the reasons you'd go with a stateful rather than a stateless session bean. But, the key word here is "imagine"; like I said at the start, I am in the process of discovering the functionality of the J2ee engine and I would equally appreciate any agreement and disagreement with my line of reasoning.

Many thanks,

Colm.

[Former Member · Accepted solution]

HI,

In case of the stateless bean the concurrency problem is taken care automatically, we need not worry about what happens if there are concurrent users.

In case of stateful bean for each connection it maintains a private connection with the Database.

Refer the Link for more Info

http://help.sap.com/saphelp_nw04/helpdata/en/41/05503e30a9d549e10000000a114084/frameset.htm

[Former Member · Accepted solution]

Thanks, that really helps answer my question.

So, when you have a private data field in your bean, then you needn't worry about concurrent users if its a stateless session bean.

However, it seems from the documentation, that if your private data field is accessed by different business methods (for example, a Open, Query, Close sequence) then any private data fields used across those methods are state relating to a specific client, and the bean needs to be a stateful session bean to ensure consistency and predictability.

In summary, the difference seems analagous to TCP (stateful, like ftp) vs. UDP (stateless, like mail).

Thanks again,

Colm.

[Benny · Accepted solution]

You need to!

Actually stateful and stateless beans only defer by their definition in the descriptor. If you fill up a statless beans private fields and release it, your code needs to make sure that those fields are deleted in ejbpassivate().

Otherwise you will see the funny effect that on the next call your "new" bean may contain data already, as it was cached by the system.

Actually not that funny in some scenarios...

Regards,

Benny

[former_member184385]

Hi Colm,

i would like to respond to your session bean example with a small story.

One of many proverbs of the financial wizard Kostolany was: "If you go to stock exchange, get quick in, do your business and get quick out".

I think, server components (aka SLSBs) should be treated similar:

- do your business means for SLSBs: do substantial work, not just tidbits, which as a consequence leads to many visits (calls)

- at the stock exchange, you do not leave something behind you, like your wallet, means for SLSBs: don not leave connections or other resources, not meant for indiscriminate shared access behind you, before you leave

Regards

Gregor .. and Greetings from Kostolany

[Former Member]

Thanks Gregor,

that reaffirms my belief that I need to use a SFSB for this particular application. It's not possible for a client to complete a quick piece of business as in your stock exchange scenario, so a SFSB it must be.

Colm.

[Former Member]

hi colm ,

I would like to suggest few missing information in this discussion.

1. Your core question-reg.

EJB container takes care of multiple client requests by load balancing and INSTANTIATING MULTIPLE INSTANCES of the single-threaded components. So it's safe,right. NO multi-threading complexity r here in beans.

2. Why statefull is not prefered.?

there r a number of reasons for the connection(state) to fail(crashed bean or network failure), Only high end bean containers have recovery capability. so if possible avoid stateful session beans..

hope this is some useful piece of information to u.

regards,

arul sekar

[Former Member]

Thanks Arul,

I understand from your answer that if you have a 'Connection' field (i.e. a class-level variable) in your SLSB, and there are N clients invoking your SLSB, then there will be N Connection variables in the J2EE engine.

However, is the client i always guaranteed to be communicating with the same SLSB instance i across method calls on that SLSB ? This question is motivated by the following definitions, taken from a textbook 'Beginning J2EE 1.4':

SLSB - These beans do not declare any instance (class-level) variables so that the methods contained within can only act upon any local parameters. There is no way to maintain state across method calls.

SFSB - These beans can hold client state across method invocations. This is possible with the use of instance variables declared in the class definition. The client will then set the values for these variables and then use these values in other method calls.

Thanks again,

Colm.

[Benny]

Hi Colm,

wow, you had some traffic here. Don't take your book too serious. It talks about theory and how you <i>should</i> implement.

In fact stateless and stateful do only differ by a definition in your descriptors. This means that the exact same code <i>could</i> run as both. Nobody checks for this - as long as you don't.

I think I wrote this before: Actually you could have class variables in a stateless bean and then would see the funny effect that if that bean comes back from the pool a caller would be able to read that data. of course this should be avoided!

Regards,

Benny

[Former Member]

Hi Colm,

regarding to you question, you have to take into consideration, that most AppServers (means all) treat a SLSB as a shared (and pooled) resource, means a Bean might serve various concurrent requests. That affects your private variables obviously. In case of SFSB only one client is "attached" to one bean, concurrency aspects don't matter in this case.

Activating and passivating the bean is to be taken into consideration AFAIK only in case of SFSB; then you have to be aware of all variables being serializable OR transient OR to be set to null within ejbPassivate() and to be re-initialized within ejbActivate().

Hope that helps

M.

[Former Member]

Thanks Matthias, that's a helpful answer. I'm not familiar with ejbActivate/Passivate, so obviously need to do some research if I want to use a SFSB.

Colm.

[Former Member]

... thankxx !

So ejbActivate/ejbPassivate is a mechanism which might be used by App.-Servers to free-up memory due to serialization (transformation into Bytes) and write the object (here SFSB) to a second storage medium (not sure where in WebAS), in most cases just to the filesystem.

As every object has to marked as serializable (due to implementing the interface java.io.Serializable) to be able to be serialized; so you have to take care of every (reference) variable to have this interface implemented. Otherwise you will end-up in Exceptions (NonSerializableException or so, not sure about the Exception class). Being marked as serializable - AFAIK - is not the case with Connections. SFSB therefore offer these both methods which are invoked by the container to give one the chance to do some housekeeping prior to passivation (ejbPassivate) or after activation

(ejbActivate / means de-serialization).

One more thing to take into consideration is a timeout which could be configured. Regardless wether the bean is passivated or not, after a certain period of unactivity the instance will be destroyed and is no longer available.

In contrast to this behavior of SFSB, SLSB are pooled resources, means after a invocation of remove by the client those instances go to a pool and are ready to server other clients.

Regards

M.

[Former Member]

Thanks Matthias, I was not aware that SLSBs are pooled resources, and SFSBs are not. Can you clarify what you mean by "after an invocation of remove by the client" ? Are you referring to a bean method called remove ? Or do you mean an action taken by the J2EE server on the bean (such as ejbPassivate) when the client goes away ?

Thanks again,

Colm.

[Former Member]

... Can you clarify what you mean by "after an invocation of remove by the client" ? Are you referring to a bean method called remove ?

I'm talking about invocation of remove() by the client. This method is provided by etxtending EJBHome Interface within your Home-Interface and is mapped to the Bean implementation as ejbRemove() (where you could do some housekeeping ud neccessary).

Regards

M.

[Benny]

Hi Colm,

I'm sorry to say that it's not that easy as Kirupanand thinks. There is no such thing as "automatic handling" of a stateless beans database connection. This is appropriate for entity beans.

If you are using session beans, your accessing the DB as usual from any other program. So if you keep some variable in the bean and write it back to the DB you usually check in that call if the record has changed since you read it.

Something like:

UPDATE   ...
WHERE Field1= originalField1, Field2 = originalFiel2,...

Obviously this will give you an error in case the record has changed.

There is no automatic whatsoever!

Regards,

Benny

[Former Member]

Hi Benny,

thanks for your perspective. I am using a bean a little differently from the scenario you describe:

> UPDATE ...

> WHERE Field1= originalField1, Field2 = originalFiel2,...

The scenario I was thinking of is one where you have a data member called 'connection' that is private to the bean, and is used by the business methods of the bean as follows:

method1: open connection

method2: accept query and send query to connection

method3: close connection

From my understanding of the documentation, using a stateful session bean will guarantee consistency of the bean's state across method calls.

Thanks & regards,

Colm.

[Benny]

Hi Colm,

this absolutely depends on what you are doing there. What is the query actually doing?

Regards,

Benny

[Former Member]

Hi Benny,

the query is just reading data from the database (so a "SELECT ... FROM tables" type query), there is no modifications or changes to the database, so the database state is not affected.

Just as a matter of interest, how would the scenario differ if the query was updating the database?

Thanks,

Colm.

[Benny]

Hi Colm,

in that case I don't know why you think that anything could get messed. Reading is harmless to the DB (except there is some misconfirguration that would cause locks and thus cause dead locks)

The defferring thing would be that when writing you could come in trouble with concurrent reading and vice versa.

Regards,

Benny

[Former Member]

Hi Benny,

No, I'm not concerned with the data in DB at all. What I am concerned about is the Connection variable, which is a local data field in the bean. Specifically, I am concerned about the scenario whereby client 1 could be reading data from the database, and in the middle of all that, client 2 comes along and asks for a connection to a different database, resulting in the Connection variable being reset.

My understanding is that to take care of that scenario, I need to make the bean a stateful session bean. A stateless session bean will not do, because (I guess as the name suggests) the bean state will not be maintained across calls on the bean.

Thanks for your thoughts and input on this,

Colm.