jump to navigation

Session Tracking August 23, 2005

Posted by Coolguy in J2EE.
trackback

Session Tracking Mechanisms

  • Cookies : Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server, unambiguously associating the request with a session. The name of the session tracking cookie must be JSESSIONID.
  • SSL Sessions : Secure Sockets Layer, the encryption technology used in the HTTPS protocol, has abuilt-in mechanism allowing multiple requests from a client to be unambiguously identified as being part of a session. A servlet container can easily use this data to define a session.
  • URL Rewriting : When a client will not accept a cookie, URL rewriting may be used by the server as the basis for session tracking. URL rewriting involves adding data, a session ID, to the URL path that is interpreted by the container to associate the request with a session. The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. Here is an example of a URL containing encoded path information:http://www.myserver.com/catalog/index.html;jsessionid=1234
  • A client joins a session when session tracking information has been returned to the server indicating that a session has been established.
  • HttpSession objects must be scoped at the application (or servlet context) level.
  • Object referenced, including the attributes in that object, must never be shared between contexts by the container.
  • A servlet can bind an object attribute into an HttpSession implementation by name. Any object bound into a session is available to any other servlet that belongs to the same ServletContext and handles a request identified as being a part of the same session.
  • Some objects may require notification when they are placed into, or removed from, a session. This information can be obtained by having the object implement the HttpSessionBindingListener interface.
  • This interface defines the following methods that will signal an object being bound into, or being unbound from, a session.• valueBound• valueUnbound
  • The valueBound method must be called before the object is made available via the getAttribute method of the HttpSession interface.
  • The valueUnbound method must be called after the object is no longer available via the getAttributemethod of the HttpSession interface.
  • The default timeout period for sessions is defined by the servlet container and can be obtained via the getMaxInactiveInterval method of the HttpSession interface.
  • This timeout can be changed by the Developer using the setMaxInactiveInterval method of the HttpSession interface. The timeout periods used by these methods are defined in seconds.
  • If the timeout period for a session is set to -1, the session will never expire.
  • The session invalidation will not take effect until all servlets using that session have exited theservice method.
  • The getLastAccessedTime method of the HttpSession interface allows a servlet to determine the last time the session was accessed before the current request.
  • Multiple servlets executing request threads may have active access to a single session object at the same time.
  • Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine1 (“JVM”) at a time.
  • The distributed servlet container must support the mechanism necessary for migrating objects that implement Serializable.
  • In distributes systems, the Container Provider can ensure scalability and quality of service featureslike load-balancing and failover by having the ability to move a session object, and its contents, from any active node of the distributed system to a different node of the system.
  • Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session.
  • Developer should always assume that all windows of a client are participating in the same session.
Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: