JSP session details (below)

Address: http://www.egzcn.com/article/webbc/JSP/2006-03-22/2002.html

 

5. Understand javax. servlet. http. HttpSession
HttpSession is the Java platform's Implementation specification for the session mechanism, because it is only an interface, specific to the provider of each web application server, in addition to the support for the specification, there are still some minor differences that are not specified in the specification. Here we use the Weblogic Server8.1 of BEA as an example.

First, Weblogic Server provides a series of parameters to control the implementation of its HttpSession, including the cookie switch option, the URL rewrite switch option, and session persistence settings, set the session expiration time and cookie settings, such as the cookie name, path, domain, and cookie survival time.

Generally, sessions are stored in the memory. When the server process is stopped or restarted, the sessions in the memory are also cleared. If session persistence is set, the server saves the session to the hard disk. When the server process is restarted or the information can be used again, weblogic Server supports persistence methods including file, database, and client cookie storage and replication.

Replication is not stored persistently, because the session is actually stored in the memory, but the same information is copied to the server processes in each cluster, in this way, even if a server process stops working, the session can still be obtained from other processes.

The cookie survival time setting affects whether the cookie generated by the browser is a session cookie. Session cookies are used by default. If you are interested, you can use it to test the misunderstanding we mentioned in section 4.

The cookie Path is a very important option for web applications. Weblogic Server's default processing method for this option makes it significantly different from other servers. We will discuss this topic later.

Session settings reference [5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

Vi. HttpSession FAQs
(In this section, the session meaning is a mixture of 5 and 6)

1. When the session is created
A common misunderstanding is that the session is created when a client accesses it. However, the fact is that the session is created until a server program calls HttpServletRequest. A statement such as getSession (true) is created. Note that if JSP is not displayed, <% @ page session = "false" %> disable the session, when the JSP file is compiled into Servlet, the following statement is automatically added: HttpSession session = HttpServletRequest. getSession (true); this is also the source of the implicit session Object in JSP.

Because the session consumes memory resources, if you do not plan to use the session, you should disable it in all JSPs.

2. When the session is deleted
Based on the previous discussion, the session is deleted under the following circumstances. the program calls HttpSession. invalidate (); or B. the interval between the session id sent by the client last time exceeds the session Timeout setting; or c. server process stopped (non-persistent session)

3. How to delete a session when the browser is closed
Strictly speaking, this cannot be done. One way to do this is to use the javascript code window. oncolose on all client pages to monitor the closing action of the browser, and then send a request to the server to delete the session. However, there is no way to break down the browser or forcibly kill the process.

4. Why is there an HttpSessionListener?
You can create listener to monitor the creation and destruction events of sessions, so that you can do some relevant work when such events occur. Note that the listener action is triggered by the session creation and destruction, rather than the opposite. Similar listener related to HttpSession include HttpSessionBindingListener, HttpSessionActivationListener, and HttpSessionAttributeListener.

5. Must the objects stored in the session be serializable?
Not required. Objects are required to be serializable only for the session to be copied in the cluster or to be permanently saved or, if necessary, the server can temporarily swap the session out of memory. If you place an unserializable object in the Weblogic Server session, you will receive a warning on the console. If a session of an iPlanet version that I have used contains an object that cannot be serialized, an Exception occurs when the session is destroyed, which is strange.

6. How can I properly handle the possibility of disabling cookies on the client?
Use URL rewriting for all URLs, including hyperlinks, form actions, and redirection URLs. For more information, see [6].
Http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7. Opening two browser windows to access the application will use the same session or different sessions
For more information, see section 3 on cookie. For session, the session only recognizes IDs and does not recognize people. Therefore, different browsers, different window opening methods and different cookie storage methods will affect the answer to this question.

8. How to Prevent session confusion caused by opening two browser windows?
This problem is similar to preventing forms from being submitted multiple times. You can solve it by setting the token of the client. It means that each time the server generates a different ID and returns it to the client and saves it in the session, the client must also return this ID to the server when submitting the form, the program first checks whether the returned ID is consistent with the value saved in the session. Otherwise, this operation has been submitted. See the section on presentation layer mode in J2EE Core mode. It should be noted that for the use of JavaScript window. generally, this ID is not set for an open window, or a separate ID is used to prevent the main window from being operated. in the open window, modify the settings.

9. Why do I need to call session. setvalue again after changing the session value in Weblogic server?
The main purpose of this operation is to prompt that the WebLogic Server session value has changed in the cluster environment. You need to copy the new session value to other server processes.

10. Why does the session disappear?
Aside from the normal failure of the session, the possibility of the server itself should be minimal, although I have encountered some patches in the Solaris version of iplanet6sp1; the possibility of browser plug-ins is second to that, I have also encountered problems caused by 3721 plug-ins. Theoretically, the firewall or proxy server may also have problems in cookie processing.
Most of the reasons for this problem are program errors. The most common reason is to access another application in one application. We will discuss this issue in the next section.

7. Cross-Application Session sharing

It is often the case that a large project is divided into several small projects for development. In order to be able to do not interfere with each other, each small project is required to be developed as a separate web application, in the end, however, we suddenly found that some information needs to be shared between several small projects, or we wanted to use the session to implement SSO (Single Sign on) and save the login user information in the session, the most natural requirement is that applications can access each other's sessions.

However, according to the Servlet specification, the scope of the session should be limited to the current application. Different applications cannot access each other's sessions. Each application server complies with this specification in terms of actual results, but the implementation details may vary. Therefore, the methods for cross-application session sharing vary.

First, let's take a look at how Tomcat isolates sessions between web applications. From the cookie path set by Tomcat, it sets different cookie paths for different applications, in this way, the session IDs used by different applications are different. Therefore, even if you access different applications in the same browser window, the session IDs sent to the server can be different.

Based on this feature, we can infer that the memory structure of the session in Tomcat is roughly as follows.

The iPlanet used by the pen is also in the same way. It is estimated that there will not be much difference between SunONE and iPlanet. For servers in this way, the solution is simple, and it is not difficult to implement it in practice. Either allow all applications to share a session id or allow the application to obtain the session id of other applications.

IPlanet has a very simple way to share a session id, that is, to set the cookie Path of each application to/(actually it should be/NASApp, for an application, it serves as the root ).
<Session-info>
<Path>/NASApp </path>
</Session-info>

It should be noted that the shared session should follow some programming conventions, such as adding the application prefix before the session attribute name, so that setAttribute ("name", "neo ") setAttribute ("app1.name", "neo") to prevent namespace conflicts and overwrite each other.

In Tomcat, there is no such convenient choice. In Tomcat version 3, we can also share sessions. For Tomcat Versions later than version 4, I have not found a simple method. You can only use the power of a third party, such as using files, databases, JMS, or client cookies, URL parameters, or hidden fields.

Let's take a look at how Weblogic Server Processes sessions.

On the screenshot, we can see that the cookie path set by Weblogic Server for all applications is/. Does this mean that the session can be shared by default on Weblogic Server? However, a small experiment proves that even if different applications use the same session, each application can only access the attributes set by itself. This indicates that the memory structure of the session in Weblogic Server may be as follows:

For such a structure, it is impossible to solve the session Sharing Problem in the session mechanism itself. In addition to the power of a third party, such as the use of files, databases, JMS or client cookies, URL parameters, or hidden fields, there is also a more convenient approach, put the session of an application into ServletContext, so that another application can obtain the reference of the previous application from ServletContext. The sample code is as follows,

Application
Context. setAttribute ("appA", session );

Application B
ContextA = context. getContext ("/appA ");
HttpSession sessionA = (HttpSession) contextA. getAttribute ("appA ");

It is worth noting that this kind of usage cannot be transplanted, because according to the JavaDoc of ServletContext, the application server can be in security for context. getContext ("/appA"); returns a null value. The preceding method is used in Weblogic Server 8.1.

So why does Weblogic Server set the cookie Path of all applications? Originally for SSO, all applications that share this session can share the authentication information. A simple experiment can prove this by modifying the descriptor of the application that was first logged on to weblogic. xml, changing the cookie Path to/appA to access another application will re-require logon. Even if it is reversed, access the application whose cookie Path is/first, and then access the modified path, although logon is not prompted, the user information will be lost. Note that the FORM authentication method should be used in this experiment, because browsers and web servers have other processing methods for the basic authentication method, and the second request authentication is not implemented through session. For details, see [7] secion 14.8 Authorization. You can modify the example program to perform these experiments.

VIII. Summary
The session mechanism is not complex, but its implementation and configuration flexibility make the specific situation complex and changeable. This also requires us not to regard the experience of a single browser or server as a general experience, but to always analyze the specific situation.