Where to keep client state

[David Follow]

Hi all,

is there a good rule of thumb where to keep client state?

The options are a) in a servlet, or b) in a stateful session bean.
Stateless session beans are not an option since you only would
use them to implement services, plus they are stateless

I understand that you use SFSB if you need the state "close to the business logic", but what does that really mean?
When would you keep the state in a servlet assuming your business logic
resides in EJBs....

D.

[Deepak Pant]

Originally posted by David Follow:
Hi all,

is there a good rule of thumb where to keep client state?

The options are a) in a servlet, or b) in a stateful session bean.
Stateless session beans are not an option since you only would
use them to implement services, plus they are stateless

I understand that you use SFSB if you need the state "close to the business logic", but what does that really mean?
When would you keep the state in a servlet assuming your business logic
resides in EJBs....

D.

David,

Look at the requirements... the design has to support atleast two clients to start with (WEB+SWING). In future there might be more types of client coming after the application. Use this to decide where should the state be maintained.

Deepak

[David Follow]

Originally posted by Deepak Pant:


David,

Look at the requirements... the design has to support atleast two clients to start with (WEB+SWING). In future there might be more types of client coming after the application. Use this to decide where should the state be maintained.

Deepak

Deepak,

I understand that if I have several different clients, especially a Web and a Swing client I probably go for SFSB. But what if I only will have a web client?
Will I keep state in the HttpSession or in a SFSB? I guess it also depends
on the amount of session data to be kept.
I still wonder if there is such thing as a general rule that applies in most of the cases.

Can somebody suggest good reading material that covers that issue?

D.

[Lucy Hummel]

Hi David,

[1] stated that you should use SFSB to manage client state. I do not have the book right here, that is why I can not list any reasons for the recommondation.


Lucy

References:
[1] Deepak Alur, John Crupi, Dan Malks: Core J2EE Patterns, Prentice Hall

[David Follow]

Originally posted by Lucy Hummel:
Hi David,

[1] stated that you should use SFSB to manage client state. I do not have the book right here, that is why I can not list any reasons for the recommondation.


Lucy

References:
[1] Deepak Alur, John Crupi, Dan Malks: Core J2EE Patterns, Prentice Hall

Hi Lucy,

true, but I can also keep client state in a HttpSession of the web container. So how do I decide whether to keep state in HttpSession or in a SFSB?

D.

[Joe Nguyen]

By keeping in the httpSession, you're tempting to use stateless session bean in place of stateful session bean; this practice increases overhead and have been considered to be bad practice (google).
It depends on where state's belong to. If it's belong to HttpSession, then it 's better be in the HttpSession. Otherwise, it's be in the stateful sb

[David Follow]

Originally posted by Joe Nguyen:
By keeping in the httpSession, you're tempting to use stateless session bean in place of stateful session bean; this practice increases overhead and have been considered to be bad practice (google).
It depends on where state's belong to. If it's belong to HttpSession, then it 's better be in the HttpSession. Otherwise, it's be in the stateful sb

Hi Joe,

why does it increase overhead? On the contrary, it should decrease overhead
since I soley use leightweight SLSB and no expensive SFSB. On the other hand, I will have to pass more data as parameters over the wires since I have to always post all the state information to the SLSB.
The client state belongs to the client, so technically it should be kept in the HttpSession, but on the other hand business logic has to work with client information so EJBs work with the client state, so one may say it belongs to a SFSB...

Can you post your resource where saying that keeping client state in HttpSession and using SLSB is concidered bad practice?

D.

[Chandramouli Ram]

Hi,

Here is a link that gives some "quantitative" results:
http://www.sys-con.com/weblogic/articleprint.cfm?id=101

Apart from this, there is a big chain of discussion on the server side.com

http://www.theserverside.com/discussions/thread.tss?thread_id=552

In any case, it depends on the requirements of the system that one is designing, and so I agree with the points that Deepak has raised. As many people have pointed out, certification is only a means and not the goal, these discussions are very thought provoking and hence relevant.

[David Follow]

Hi Ram,

thanks for the links. after studying them, I came up with a conclusion (maybe not with a rule of thumb). I guess if you need to take care of the client state regarding presentation logic, then I would keep that state in HttpSession. However, if you need to keep state regarding business logic, I would prefer to keep it in a SFSB.
Further, if you think there will be several channels hitting your app, then keeping state in SFSB may be the best, that way you don't have to implement client state handling for each and every new channel e.g. web-, WAP- or thin-client channels and so forth.

D.

[Bhanu]

There may not be any rule of thumbs to Architects(future). We have to take decisons on trade offs based on circumstances.But anyway this discussion is informative.

[Gopal Chiluki]

shouldn't be the state a combination of cookies, httpsession and stateful session bean ?
What I mean,
say if the user connects to the site, a cookie will be set on the browser which has a reference to httpsession in the web tier. And the web tier maintains the user's state to temporararly store some of user specific(to be accurate session specicic) data. This is needed to maintain the state between in stataless session beans. And also stateless beans maintains the some of the client state.

Any comments from anyone?

[Gopal Chiluki]

small correction to my previous state.

I meant to say, stateful session beans also maintains client state for some of the data