Contents written to the persistent store using a database
WebSphere supports two modes for writing session contents to the persistent store:
- Only updated attributes
Write only the HttpSession properties updated via setAttribute() and removeAttribute().
- All session attributes
Write all the HttpSession properties to the database.
When a new session is initially created with either of the above two options, the entire session is written, including any Java objects bound to the session. When using database persistence, the behavior for subsequent servlet or JSP requests for this session varies depending on whether the single-row or multi-row database mode is in use.
In single-row mode, choose from the following:
- Only updated attributes
If any session attribute has been updated, through setAttribute or removeAttribute, then all of the objects bound to the session will be written to the database.
- All session attributes
All bound session attributes will be written to the database.
In multi-row mode:
- Only updated attributes
Only the session attributes that were specified via setAttribute or removeAttribute will be written to the database.
- All session attributes
- Only updated attributes
All of the session attributes that reside in the cache will be written to the database. If the session has never left the cache, then this should contain all of the session attributes.
By using the All session attributes mode, servlets and JSPs can change Java objects that are attributes of the HttpSession without having to call setAttribute() on the HttpSession for that Java object in order for the changes to be reflected in the database.
Using the All session attributes mode provides some flexibility to the application programmer and protects against possible side effects of moving from local sessions to persistent sessions.
However, using All session attributes mode can potentially increase activity and be a performance drain. Individual customers will have to evaluate the pros and cons for their installation. It should be noted that the combination of All session attributes mode with time-based write could greatly reduce the performance penalty and essentially give you the best of both worlds.
As shown in Example 10-9 and Example 10-10, the initial session creation contains a setAttribute, but subsequent requests for that session do not need to use setAttribute.
Example 10-9 Initial servlet
HttpSession sess = request.getSession(true);
myClass myObject = new myClass();
myObject.someInt = 1;
sess.setAttribute("myObject", myObject); // Bind object to the session
Example 10-10 Subsequent servlet
HttpSession sess = request.getSession(false);
myObject = sess.getAttribute("myObject"); // get bound session object
myObject.someInt++; // change the session object
// setAttribute() not needed with write "All session attributes" specified
Example 10-11 and Example 10-12 show setAttribute is still required even though the write all session attributes option is enabled.
Example 10-11 Initial servlet
HttpSession sess = request.getSession(true);
String myString = new String("Initial Binding of Session Object");
sess.setAttribute("myString", myString); // Bind object to the session
Example 10-12 Subsequent servlet
HttpSession sess = request.getSession(false);
String myString = sess.getAttribute("myString"); // get bound session object
...
myString = new String("A totally new String"); // get a new String object
sess.setAttribute("myString", myString); // Need to bind the object to the session since a NEW Object is used
