Hi there,
Has any body managed to get the example which is in
doc/guides/ejb/examples/converter of the j2sdkee3.1 application server to
work, b'cause I am having trouble deploying it.
any help will be appreciated.
Regards,
Ravindra Kakani
-----Original Message-----
From: Bartsch Axel [mailto:[EMAIL PROTECTED]]
Sent: Monday, 26 February 2001 10:23 p.m.
To: [EMAIL PROTECTED]
Subject: Re: sessions across multiple servers
Hi,
I am using the Tomcat servlet engine together with the Apache Web Server.
The session Id is stored in the cookie.
After the user logs in using servlet1 at JVM1 a session is created.
Subsequent requests
should then use the same session. These requests may be treated by other
servlets running
at other JVMs: the requests arrive there either using a button with a HREF
to that servlet (this button was sent to the browser in the response of
servlet1) or by servlet1 forwarding (request dispatcher) the request to a
servlet of another JVM.
Now to be clear:
You are saying that the session will be available also at these servlets
running at other JVMs?
Is that so?
My question:
1)
How does the servlet engine know that it must copy the Session context
object into a file so that it can be restored at the other JVMs? is this
done by configuration of the servlet engine or does the servlet programmer
have to take care of this?
2) does all this work only if all JVMs are under control of the same servlet
engine or does it also work if the different servlets run under control of
different servlet engines (multiple instances of Tomcat)?
Axel Lannion/France
> -----Original Message-----
> From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
> Sent: vendredi 23 f> évrier 2001 21:20
> To: [EMAIL PROTECTED]
> Subject: Re: sessions across multiple servers
>
> Bartsch Axel wrote:
>
> > Hi Christopher,
> >
> > Thanks for your answer.
> >
> > Does that mean that the session object itself is always passed to all
servlets also running across different JVMs and that no change at creating
and using the session object is necessary? Is the session object therefore
made Serializable?
> >
>
> The session object itself will generally (but not always) implement
Serializable -- but you don't have to worry about that.
>
> What you as an application developer need to ensure is that any session
attributes you create must implement Serializable (as must any instance
variables that you maintain within that class), so that the application
server can copy them if
> needed.
>
> >
> > Therefore if I would not store any objects in my session the session
would work fine for authentication and session timeout
> > purposes also across different JVMs?
> > Only if I want to store objects I have to make them Serializable?
> >
>
> Anything that is stored in the session (when running a <distributable>
application) needs to be Serializable. That includes any objects you are
storing there for authentication or timeout purposes.
>
> >
> > I am using the cookie method to store the session Id. Do you know what
is stored in the cookie:only the sessionId or also the timestamp of the
latest click?
> >
>
> Details vary by servlet container, but the timestamp is probably not
included (it is definitely not included in Tomcat). The reason is that
there is no need for the client to know about that -- session timeout is a
server side thing, and
> happens even if the client goes away and never comes back.
>
> Apache JServ and Tomcat have a limited form of "load balancing", where
they randomly distribute non-session requests among the various servers, but
once you start a session they leave you on a particular server for the
remainder of that
> session. To do this, the load balancing code adds a host identifier to
the session id, so that it knows where to direct subsequent requests for
this session.
>
> But all of this is platform specific -- an application cannot assume
anything about the internal contents of a session identifier.
>
> >
> > Axel Lannion/France
> >
>
> Craig McClanahan
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html>
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
