®

IBM Software Group

Session Persistence Mechanism in IBM

WebSphere Application Server

Varun Tallapragada (varunt@us.ibm.com)

WebSphere Application Server L2 Support
15 December 2010

WebSphere® Support Technical Exchange

 IBM Software Group

Agenda
 Overview of HTTP Session Management
 WebSphere Application Server & Session Management
 Local sessions
 Persistence mechanisms
 Database persistence
 Memory-to-memory replication
 Problem determination
 Best practices
 Resources
 Q&A

WebSphere ® Support Technical Exchange 2 of 42

 IBM Software Group

HTTP Session Management

WebSphere ® Support Technical Exchange 3 of 42

 IBM Software Group

HTTP Session management

What is HTTP Session:

Implementing the HTTP Session allows a web application developer to maintain state information across multiple user visits to
the application.
HTTP Session API:

 Creating/Accessing Session:
 HttpSession session = request.getSession(boolean create)
 HttpSession session = request.getSession()
 Verifying if session is a new session:
 Session.isNew()
 Dealing with HTTP Session attributes:
 getAttribute(String name)
 setAttribute(String name, Object val)
 removeAttribute()
 When / How long:
 getCreationTime()
 getLastAccessedTime()
 getMaxInactiveInterval()
 setMaxInactiveInterval()

WebSphere ® Support Technical Exchange 4 of 42

 IBM Software Group

Session listeners:
 Session Create or Destroy:
 HTTPSessionListener
• sessionCreated()
• sessionDestroyed()
 Session Attributes:
 HttpSessionAttributeListener
• attributeAdded()
• attrbuteRemoved()
• attributeReplaced()
 Session Activation:
 HttpSesessionActivationListener
• sessionActivated()
• sessionPassivated()
 Session Binding Events:
 HttpSessionBindingListener
• valueBound()
• valueUnbound()
 com.ibm.websphere.servlet.session.IBMSessionListener

WebSphere ® Support Technical Exchange 5 of 42

 IBM Software Group

WebSphere & HTTP Session management

WebSphere ® Support Technical Exchange 6 of 42

 IBM Software Group

Session Manager configuration

 Configuration can be done at various levels
 Application Server level.
• Applied to all Web modules in the server.
 Enterprise Application level.
• Applied to all Web modules in the App.
 Web Application level.
• Applied to the specified web module.
 Choosing a session tracking mechanism:
WebSphere application server support the following session tracking mechanisms:
 Enable SSL ID tracking (deprecated)
 Cookies
 URL Rewriting
• Enable protocol switch rewriting

WebSphere ® Support Technical Exchange 7 of 42

 IBM Software Group

Server level Cookies

WebSphere ® Support Technical Exchange 8 of 42

 IBM Software Group

Session cookie

JSESSIONID=0002wJXDXci_VotW v84L6nNMaN3:15ej9t1j5:15ej9t4hc

 CacheId : 0002

 CloneSeperator : “:”

 SessionId : wJXDXci_VotWv84L6nNMaN3

 CloneId’s : 15ej9t1j5 and 15ej9t4hc

WebSphere ® Support Technical Exchange 9 of 42

 IBM Software Group

Application level

WebSphere ® Support Technical Exchange 10 of 42

 IBM Software Group

Session management properties

 Maximum In-memory session count

Allow Overflow

 Session Timeout
No timeout
Set timeout

 Security Integration

 Serialize Session Access

Allow Serial access
•Maximum Wait time in sec.
•Allow access on Timeout

WebSphere ® Support Technical Exchange 11 of 42

 IBM Software Group

Local sessions

WebSphere ® Support Technical Exchange 12 of 42

 IBM Software Group

Local Sessions
 The local/in-memory session cache keeps session information in memory and local to the
machine and WebSphere Application Server where the session information was first
created.

 Local session management does not share user session information with other clustered
machines. Users only obtain their session information if they return to the application
server

 Session data will be lost, during the fail-over and also if server goes down or server
recycle

 Users will be impacted during the server outage.

Note : “Allow overflow” is only for the non-distributed sessions.

WebSphere ® Support Technical Exchange 13 of 42

 IBM Software Group

Local sessions

WebSphere ® Support Technical Exchange 14 of 42

 IBM Software Group

Persistence mechanisms

WebSphere ® Support Technical Exchange 15 of 42

 IBM Software Group

Types of persistence mechanisms

 Database persistence.
 Memory-to-memory replication.

Advantages of Session persistence:

 When the server with an existing request/session goes down, plugin will
route the request to next available cluster member.
 The user’s session data can be recovered by another cluster member
either from:
• External database
− Data base persistence
• Another server store
− Memory-to-memory Replication

WebSphere ® Support Technical Exchange 16 of 42

 IBM Software Group

Pictorial view of persistence mechanisms

WebSphere ® Support Technical Exchange 17 of 42

 IBM Software Group

Database persistence
Configuring Database persistence
 Create JDBC provide
 Create a data source for the database.
 Configure session Manager to use the data source created.

Note: Session Manager will automatically create the necessary database schema except for DB2 on z/OS. If
using DB2 on z/OS, then database administrator need to create the database schema manually. Refer the
following URL for instructions to create session schema:
Creating a DB2 table for session persistence
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/
zseries/ae/tprs_db2tzos.html

WebSphere ® Support Technical Exchange 18 of 42

 IBM Software Group

Distributed settings

WebSphere ® Support Technical Exchange 19 of 42

 IBM Software Group

Database settings

WebSphere ® Support Technical Exchange 20 of 42

 IBM Software Group

Database Persistence – Failover Scenario

 New request arrives to plug-in.
 Plug-in decides to send the request to member1.
 Application accesses the session by calling request.getSession(), session manager
creates a new session and stores in database.
 The JSESSIONID cookie will be sent back to client in the response.
 member1 is crashed/shutdown.
 Subsequent request from the same user arrives to plug-in.
 Plug-in fails to maintain affinity as the server is not reachable.
 Plug-in failover the request to next available server, member2.
 When application access the session, session manager looks for the session in its
memory and fails to find.
 Session manager will retrieve the session from the database.
 Session manager in member2 increments the cacheId from 0001 to 0002 and
updates in database and in memory.
 member2 will send the updated JSESSIONID cookie in the response.

WebSphere ® Support Technical Exchange 21 of 42

 IBM Software Group

 Very high (optimize for performance)

Tuning parameters Write frequency Time based

Write interval 300 seconds
Write contents Only updated attributes
Schedule sessions cleanup true
 Write Frequency •First time of day default 0
 End Of Service •Second time of day default 2
 Manual Update  High
Write frequency Time based
 Time Based Write interval 300 seconds
Write contents All session attributes
 Write Contents Schedule sessions cleanup false
 Only Updated attributes  Medium
 All Attributes Write frequency End of servlet service
Write contents Only updated attributes
Schedule sessions cleanup false
 Schedule Session Cleanup
 Specify schedule  Low (optimize for failover)
Write frequency End of servlet service
• First time Write contents All session attributes
• Second time Schedule sessions cleanup false

 Custom settings
Write frequency default Time based
Write interval default 10 seconds
Write contents default All session attributes
Schedule sessions cleanup default false

WebSphere ® Support Technical Exchange 22 of 42

 IBM Software Group

Tuning parameters Custom settings

WebSphere ® Support Technical Exchange 23 of 42

 IBM Software Group

WebServer Plug-in
 Load Balancing
 Distributes the load/request to all cluster members based on
Round Robin algorithm
 Session Affinity
 For all existing sessions, Plug-in sends request to the server
where session data exists in memory
 When the target server is not reachable, then request fails over
to a different server in cluster
 Plug-in uses cloneId information present in JSESSIONID cookie
of the incoming request to route request to application server

Note: In case of Memory-Memory (peer-to-peer) , session manager encodes partitionId in

JSESSIONID cookie. Plug-in uses dynamic partition table from application server to route the
request to the server where the backup data is present.

WebSphere ® Support Technical Exchange 24 of 42

 IBM Software Group

Memory-to-Memory replication
 Sessions are stored in the memory of an application server, providing the same
functionality as a database for session persistence.

 M-M persistence, eliminates the overhead and cost of setting up and maintaining a real-
time production database.

 It also eliminates the single point of failure that can occur with a database.

Data Replication Service (DRS):

 The data replication service (DRS) is an internal WebSphere Application Server
component.

 Memory-to-memory replication uses the DRS to replicate data across many application
servers in a cluster.

 Dynamic Caching and Stateful session beans are other consumers of DRS.
 Replication domain should be created (Either manually or while creating the cluster)
before configuring the DRS.

NOTE: Do not use same replication domain for Dynamic caching and sessions/Stateful.

WebSphere ® Support Technical Exchange 25 of 42

 IBM Software Group

Memory-to-Memory
Configuring Memory-to-Memory replication
 Create a replication domain.
 Select “Memory-to-Memory replication” persistence from distributed
environment settings page of session manager panel.

 Provide following general properties in Memory-to-Memory replication page.

 Replication domain.
 Replication mode.
• Server mode
• Client mode
• Both mode (Default)
Topologies supported :
 Peer-to-peer replication
 Client/server replication

WebSphere ® Support Technical Exchange 26 of 42

 IBM Software Group

Peer-to-Peer topology
 This is most commonly used topology.
 In this basic peer-to-peer topology, each application server can:

 Host the Web application

 Send changes to the HTTP session that it owns
 Receive backup copies of the HTTP session from all of the other servers in the
cluster.

 The advantage of this topology is that no additional processes and products are
required to avoid a single point of failure.

 Hot Fail over can be accomplished with this topology.

 Most stable implementation is achieved when each node has equal capabilities (CPU,
memory etc), and each handles the same amount of work.

Note: At least one backup server must be running always.

WebSphere ® Support Technical Exchange 27 of 42

 IBM Software Group

Peer-to-peer topology

WebSphere ® Support Technical Exchange 28 of 42

 IBM Software Group

Client/Server topology
 In Client/Server topology the servers act as either replication client only or a server
only.

 Application Servers Configured as Server

 Stores the session information of clients and purely acts as datastore.
 Cannot host any applications and do not respond to the user’s requests
 Store sessions in their own memory and provide session information to clients.
 These servers must be started before starting the client servers.

 Application Server Configured as Client

 These servers can host applications
 Client application servers send session information to the replication servers
and retrieve sessions from the servers.
 Respond to user requests and store only the sessions of the users with whom
they interact.

WebSphere ® Support Technical Exchange 29 of 42

 IBM Software Group

Client/Server topology

WebSphere ® Support Technical Exchange 30 of 42

 IBM Software Group

Replication domain Memory-to-Memory

WebSphere ® Support Technical Exchange 31 of 42

 IBM Software Group

Memory-to-Memory - Failover scenario

 New request arrives to plug-in.
 Plug-in decides to send the request to member1.
 Application accesses the session by calling request.getSession(), session
manager creates a new session and stores in database.
 The JSESSIONID cookie will be sent back to client in the response.
 The session gets replicated to other servers in the cluster (member2 and
member3).
 member1 is crashed/shutdown.
 Subsequent request from the same user arrives to plug-in.
 Plug-in fails to maintain affinity as the server is not reachable.
 Plug-in failover the request to next available server, member2.
 When application access the session, session manager looks for the session
in its memory.
 Session manager will retrieve the session from member2, as the session
already got replicated to this server.
 Session manager in member2 increments the cacheId from 0001 to 0002 and
updates the cache.
 member2 will send the updated JSESSIONID cookie in the response

WebSphere ® Support Technical Exchange 32 of 42

 IBM Software Group

Problem determination

WebSphere ® Support Technical Exchange 33 of 42

 IBM Software Group

Problem determination
Session Affinity is failing
 Affinity is maintained by plug-in. If WebServer plug-in is not used in the
environment, then affinity will not be maintained.
 Check if the session persistence is configured properly
 make sure latest plugin-cfg.xml is in use.
 Review the plug-in trace to see if plug-in is picking up right clone information from
session cookie as well as sending request to right server.
 If using peer-to-peer topology, then plug-in uses dynamic partition table information
to maintain affinity.
 Make sure to upgrade plug-in with application server upgrade.

 New session is created on every access from same client

 Check the value of JSESSIONID in all requests from the same client.
 Check the value for inactivation interval for a newly created session

WebSphere ® Support Technical Exchange 34 of 42

 IBM Software Group

 Session data crossover

 Get the session cookie (JSESSIONID) value for both the users
 Get the suspected session attribute
 Get the URL for the failing request when the session data was
swapped
 Verify if there are any concurrent requests been served by
WebSphere when the data was swapped.
 Add DebugSessionCrossover custom property. This will check
to verify that only the session associated with the request is
accessed or referenced.
 Add debug statements in application code.

WebSphere ® Support Technical Exchange 35 of 42

 IBM Software Group

 Session data lost

 Is all session data lost or only certain attributes?
 If only certain attributes, then make sure those objects are implementing
java.io.Serializable interface.
 Verify if there are any DB Persistence related error messages in
SystemOut, SystemError and trace files. If found, fix those errors first.
 Check if persistence is configured properly and verify the Session Tuning
settings – Write Frequency and Write Contents.
 Check to see if there is any modification to the attributes storing in session,
after calling setAttribute().
 Check if storing all session attributes in custom settings will help.

WebSphere ® Support Technical Exchange 36 of 42

 IBM Software Group

Best practices

WebSphere ® Support Technical Exchange 37 of 42

 IBM Software Group

Best practices using HTTP Sessions

 Keep amount of data stored in session minimal.

 Release HttpSession objects by invalidating the session when finished.

 Implement Serializable when developing new objects to be stored in the

HTTP session.

 When secure data is stored in session, use session and security integration
feature in secured environments.

 Avoid trying to save and reuse the HttpSession object outside of servlet or
JSP service.

 When using multi-framed pages

 Create a session in only one frame or before accessing any frame sets.
 Update session data using only in one frame.

WebSphere ® Support Technical Exchange 38 of 42

 IBM Software Group

Additional Resources for HTTP Session

 W ebSphere Appliction Server Information center
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp

 com.ibm.websphere.servlet.session.IBMSessionListner
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/
com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/websphere/servlet/session/
IBMSessionListener.html

 Best practices using HTTP Session

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/
com.ibm.websphere.express.doc/info/exp/ae/cprs_best_practice.html

 Java™ Servlet Specification

http://www.oracle.com/technetwork/java/download-139443.html

WebSphere ® Support Technical Exchange 39 of 42

 IBM Software Group

Additional WebSphere Product Resources

 Learn about upcoming WebSphere Support Technical Exchange webcasts, and access
previously recorded presentations at:
http://www.ibm.com/software/websphere/support/supp_tech.html

 Discover the latest trends in WebSphere Technology and implementation, participate in

technically-focused briefings, webcasts and podcasts at:
http://www.ibm.com/developerworks/websphere/community/
 Join the Global WebSphere Community:
http://www.websphereusergroup.org
 Access key product show-me demos and tutorials by visiting IBM® Education Assistant:
http://www.ibm.com/software/info/education/assistant

 View a webcast replay with step-by-step instructions for using the Service Request (SR)
tool for submitting problems electronically:
http://www.ibm.com/software/websphere/support/d2w.html
 Sign up to receive weekly technical My Notifications emails:
http://www.ibm.com/software/support/einfo.html

WebSphere ® Support Technical Exchange 40 of 42

 IBM Software Group

We Want to Hear From You!

Tell us about what you want to learn

Suggestions for future topics

Improvements and comments about our webcasts
We want to hear everything you have to say!

Please send your suggestions and comments to:

wsehelp@us.ibm.com

WebSphere ® Support Technical Exchange 41 of 42

 IBM Software Group

Questions and Answers

WebSphere ® Support Technical Exchange 42 of 42