Controller -Servlet or Session Bean ?

Hi all
I was wondering if any of you guys can give me a few "thumb rules" on when to use a Servlet for a controller / State Management, and when to use statefull session bean. I keep mix between the 2.
thanks

i agree with u in keeping a mix often.
For state, one indicator is ur deployment scenario.
If ur websvr is clustered, rely more on stateful SB for state.
If both websvr & appsvr r clustered, go for a mix.

Yeah - this makes sense..
However - i spotted some mock questions that didnt stated deployment env' issues. Some of the answers were of "Servlet as controller / Servlet for state holding " and some choose "Session Beans".
When the answer is Servlet, the explanasion is always "No need for Session bean". As i see it - Session bean is more heavy, but more scalable. Servlet is lightweight, but less flexible..
So - when to use what ?

I m afraid most of the times answers in such tests do not take a exhaustive view. But to be fair, in such boundary questions, people might come up with varied opinions. On more simplfied and raw terms, u can always assume :-
1)When the state u r holding in ur web layer is to be propagated across ejbs also, u got to have both approaches. May be have a java object placed in HttpSession (or Custom Web Svr own session like IBMHttpSession), then persist it through replication (bcz likely u r on clustered env in production cases), and then maintain a ref to a stateful SB which will in turn be persisted thru passivation.
example is a simple http session shopping cart holding some local entity ref thru session facade
2)In simple cases when u r just concerned with navigation and state maintainance till web svr layer, always go for Svt
Messing, in all likelihood u r knowing these. I just summarised it. Byee..

Thank you far clarifying that