Very interesting. I never did consider this. I think there are different
approaches as to the best way to accomplish this. Because the network can
get bottlenecked, I understand its best to use STATELESS ejb session beans.
That is, they simply do logic, but do not store any session information. The
session information is stored in the HttpSession instead. I don't quite know
why this prevents a bottleneck over the network. It seems to me that no
matter what you do on the web server side, you'll have to mimmick the data
on the ejb side and somehow pass that info from the web server to the ejb
session bean, have it do its work and return the data back to the web server
so that it can be stored sessionaly. However, this would resolve your
time-out problem, which among other things may be why some choose to do
this.
I don't know if you are trying to store the info twice..but if you are, I'd
not do that. Store it in the HttpSession or the EJB session, but not both.
Thus, your "bouncer" include file should be checking either the HttpSession
or calling the EJB session to check for the object there. Not both. I would
still prefer to use Stateless ejb beans and store everything in the
HttpSession. Maybe the bottleneck is because the "view" is on the web
server..and you may often need to view dynamic content far more than you
deal with transactions..so it makes sense to store info in the HttpSession
and just use stateless ejb to do the work.
Make any sense? ;)
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Munro
> Sent: Thursday, May 04, 2000 9:37 AM
> To: Orion-Interest
> Subject: Stateful Session timeout, JSPs
>
>
> Hello
>
> I have a design question.
>
> I have a (1) JSP session which stores a reference to (2) a stateful
> session EJB. If either times out, I want the user to be bounced to a page
> where they have to log in (again). The problem is that the JSP session
> and the session EJB time out under different conditions -- that is to say,
> merely surfing around the web application will keep the JSP session alive,
> but the EJB is only kept alive by accessing it, which doesn't necessarily
> happen on every page. Otherwise, I could simply set the EJB to timeout
> after a longer time than the JSP session.
>
> I have a <%@ include file="/system/bouncer.jsp" %> at the top of all my
> JSP pages, which tests whether the JSP session has timed out (among other
> things), and if so, it bounces to the log-in page.
>
> However, for the session EJB, I have to catch
> "java.rmi.NoSuchObjectException: Session has timed out" to know that the
> EJB has expired.
>
> In the interests of tidiness, I am inclined to try to put this test in the
> same included file.
>
> Which is the better design? (A) to make a dummy method "ping()" on my
> EJB, and then try to call it inside a try block from the included JSP (=
> extra network hit per page view), or (B) make each JSP page which uses the
> EJB capable of redirecting to the log-in page if the Exception is thrown
> (thus coding the same thing in many places, and potentially introducing
> the need to buffer everything, in order to be able to
> response.sendRedirect()).
>
> Or perhaps (C), I'm way off the mark (I'm not using JavaBeans or a taglib
> to access the EJB, for example, which might well be the source of my
> vexation).
>
> Opinions, solutions, experiences much appreciated.
>
>
> --
> Thomas Munro <[EMAIL PROTECTED]> "Travelling through hyperspace
> http://www.gi-technology.com/ isn't like dusting crops, boy."
> GI Technology (Paris)
>
>
