• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Where to keep client state

 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
small correction to my previous state.

I meant to say, stateful session beans also maintains client state for some of the data
 
I RELEASE YOU! (for now .... ) Feel free to peruse this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic