Java Basics-A detailed explanation of the session

Transferred from: http://hi.baidu.com/zbzbzb/item/65d73d2a4d07cfd40f37f900

First, the term session

In my experience, the term "session" is probably second only to transaction, and more interestingly, the meaning of transaction and the session in some contexts is the same.

Session, Chinese is often translated into a conversation, its original meaning refers to the beginning and end of a series of actions/messages, such as the phone from the pick up the phone to dial to hang up the phone in the middle of a series of processes can be called a session. Sometimes we can see the words "during a browser session, ...", where the term "session" is used in its original meaning, refers to open from a browser window to close this period ①. The most confusing is the phrase "User (client) during a session", which may refer to a series of actions by a user (typically a series of actions related to a specific purpose, such as a process of online shopping from login to purchase to checkout, sometimes referred to as a transaction) , but sometimes it may just be a connection, or it may refer to the meaning of ①, where the difference can only be inferred by context ②.

However, when the term session is associated with a network protocol, it often implies a "connection-oriented" and/or "hold state" of the two meanings, "connection-oriented" refers to the communication between the two parties before communication to establish a channel of communication, such as telephone, until the other side of the phone communication to start, In contrast to writing letters, when you send out the letter you can not confirm the other person's address is correct, communication channels may not be able to establish, but for the sender, the communication has begun. "Hold state" means that the party of communication can associate a series of messages, so that the message can be interdependent, such as a waiter can recognize the return of the old customers and remember the last time the customer owed a money in the store. Examples of this type are "a TCP session" or "a POP3 session" ③.

In the era of the development of Web server, the semantics of the session in the context of web development has a new extension, which means a kind of solution ④ to maintain state between client and server. Sometimes the session is used to refer to the storage structure of this solution, such as "Keep XXX in Session" ⑤. Because the various languages used for Web development provide support for this solution to a certain extent, the session is also used to refer to the solution of the language in a particular language context, For example, the javax.servlet.http.HttpSession provided in Java is referred to as Session⑥.

Given that this confusion has not changed, the use of the term session in this article will be based on the context has different meanings, please pay attention to distinguish.

In this article, using the Chinese "browser session" to express the meaning of ①, using the "session mechanism" to express the meaning of ④, using "session" to express the meaning of ⑤, the use of specific "HttpSession" to express the meaning ⑥

Second, HTTP protocol and state hold

The HTTP protocol itself is stateless, which is consistent with the HTTP protocol's original purpose, the client simply needs to request to the server to download some files, both the client and the server do not need to record each other's past behavior, each request is independent, Like the relationship between a customer and a vending machine or an ordinary (non-membership) hypermarket.

Yet clever (or greedy?) People quickly discovered that providing some on-demand dynamic information would make the web more useful, like adding on-demand functionality to cable TV. This demand on the one hand, forcing HTML to gradually add the form, script, Dom and other client behavior, on the other hand on the server side of the CGI specification in response to the client's dynamic request, as a transport carrier HTTP protocol also added file upload, cookie these features. The purpose of the cookie is to resolve the HTTP protocol's stateless flaws in the efforts made. The subsequent session mechanism is another solution for maintaining state between the client and the server.

Let's use a few examples to describe the difference and connection between a cookie and a session mechanism. I used to go to a coffee shop to drink 5 cups of coffee free of charge for a cup of coffee, but a one-time consumption of 5 cups of coffee is very little, then need some way to record a customer's consumption quantity. Imagine the fact that there are several options below:

1, the shop clerk is very strong, can remember each customer's consumption quantity, as long as the customer walked into the coffee shop, the clerk knew how to treat. This approach is the protocol itself that supports the state.

2, issued to customers a card, the above record the amount of consumption, there is generally a valid period. If the customer presents this card each time it is consumed, the consumption will be linked to the previous or subsequent consumption. This practice is to keep the state on the client.

3, issued to the customer a membership card, in addition to the card number of what information is not recorded, each time the consumer, if the customer presented the card, the shop clerk in the store records found this card number corresponding record add some consumer information. This is done by keeping the state on the server side.

Since the HTTP protocol is stateless and does not want to be stateful due to various considerations, the next two scenarios become a realistic choice. In particular, the cookie mechanism uses a scheme that maintains state on the client, while the session mechanism uses a scenario that maintains state on the server side. We also see that the session mechanism may need to use a cookie mechanism to save the identity, but in fact it has other options because the server-side hold-state scheme also needs to preserve an identity on the client side.

Third, understand the cookie mechanism

The rationale for the cookie mechanism is as simple as the example above, but there are several issues to be solved: how to distribute the membership card, the content of the membership card, and how the customer uses the loyalty card.

Orthodox cookie distribution is implemented by extending the HTTP protocol, and the server prompts the browser to generate the appropriate cookie by adding a special line of instructions to the HTTP response header. However, purely client-side scripts such as JavaScript or VBScript can also generate cookies.

And the use of cookies by the browser in accordance with certain principles in the background automatically sent to the server. The browser checks all stored cookies and, if a cookie declares a scope greater than or equal to the location of the resource to be requested, sends the cookie to the server on the HTTP request header of the requesting resource. McDonald's membership card can only be presented in the McDonald's store, if a branch also issued their own membership card, then into the store in addition to show McDonald's membership card, but also to show the store's membership card.

The contents of the cookie mainly include: name, value, expiration time, path and domain.

Where a domain can specify a domain such as. google.com, which is equivalent to the head office signs, such as the company, can also specify a domain under a specific machine such as www.google.com or froogle.google.com, can be used to make the ratio of fluttering.

The path is the URL path that follows the domain name, such as/or/foo, and so on, can be used to do a certain float-soft counter.

The combination of the path and the domain constitutes the scope of the cookie.
If you do not set an expiration time, the cookie will not be in the lifetime of the browser session, as long as the browser window is closed. This cookie, which is the lifetime of the browser session, is referred to as a session cookie. Session cookies are generally not stored on the hard disk but are kept in memory, although this behavior is not regulated. If the expiration time is set, the browser will save the cookie to the hard disk, turn it off and open the browser again, and the cookies remain valid until the set expiration time expires.

Cookies stored on the hard disk can be shared between different browser processes, such as two IE windows. For cookies stored in memory, different browsers have different ways of handling them. For IE, a window that is opened by pressing CTRL-N (or from the File menu) on an open window can be shared with the original window, while the other way of opening the IE process does not share the memory cookie of the opened window; for Mozilla Firefox0.8, all processes and tabs can share the same cookie. In general, a window opened with JavaScript's window.open will share the memory cookie with the original window. The browser's approach to cookie-only recognition of session cookies is often a major problem for Web application developers who use the sessions mechanism.

Here is an example of a goolge setting a cookie's response header

http/1.1 302 Found
location:http://www.google.com/intl/zh-cn/
Set-cookie:pref=id=0565f77e132de138:nw=1:tm=1098082649:lm=1098082649:s=kaeacfpo49ria_d8; Expires=sun, 17-jan-2038 19:14:07 GMT; path=/; Domain=.google.com
Content-type:text/html

This is part of the HTTP communication record captured using Httplook this HTTP sniffer software

The browser automatically sends out cookies when accessing Goolge resources again

Using Firefox makes it easy to observe the values of existing cookies

Using Httplook with Firefox makes it easy to understand how cookies work.

IE can also be set to ask before accepting cookies

This is a dialog box asking to accept cookies.

Iv. Understanding the session mechanism

The session mechanism is a server-side mechanism that uses a hash-like structure (or perhaps a hash table) to hold information.

When a program needs to create a session for a client's request, the server first checks to see if a session ID is included in the client's request-called the session ID. If it contains a session The ID indicates that the session was previously created for this client, and the server retrieves the session using the session ID (if it is not retrieved, it may create a new one) if the client request does not include the session ID. Creates a session for this client and generates a session Id,session ID value associated with this session should be a string that is neither duplicated nor easily found to mimic the pattern, this session The ID will be returned to the client in this response to be saved.

This session ID can be saved by using a cookie, so that the browser can automatically play the logo to the server during the interactive process. Generally the name of this cookie is similar to Seeesionid, and. For example, WebLogic for Web application generation cookie,jsessionid=byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng!- 145788764, its name is Jsessionid.

Since cookies can be artificially banned, there must be other mechanisms that can still pass the session ID back to the server when the cookie is banned. A technique that is often used is called URL rewriting, where the session ID is appended directly to the URL path, and there are two additional ways to add information as a URL path, in the form of another as a query string appended to the URL, in the form of HTTP.// ...../xxx?jsessionid=byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng!-145788764
These two ways for the user is no difference, but the server in the resolution of the way the process is different, the first way is also conducive to the session ID information and normal program parameters separated.

In order to maintain state throughout the interaction, the session ID must be included after each client may request a path.

Another technique is called a form-hidden field. Is that the server automatically modifies the form, adding a hidden field so that the session ID can be passed back to the server when the form is submitted. such as the following form

will be rewritten before being passed to the client.

This technique is now less applied, and the very old IPlanet6 (the predecessor of the SunOne Application server) that the author has contacted has used this technique. In fact, this technique can be replaced simply by applying URL rewriting to the action.

When we talk about the session mechanism, I often hear a misunderstanding that "as soon as you close the browser, the session disappears." In fact, you can imagine the membership card example, unless the customer actively to the store to sell cards, otherwise the store will not easily delete customer information. For the session is the same, unless the program notifies the server to delete a session, or the server will remain, the program is generally in the user to log off when sending an instruction to delete the session. However, the browser will never proactively notify the server before shutting down, so the server will not have the opportunity to know that the browser has been shut down, the reason for this illusion is that most of the session mechanism uses a conversation cookie to save the sessions ID, The session ID disappears when you close the browser, and you cannot find the original session when you connect to the server again. If the cookie set by the server is saved to the hard disk, or if a device is used to overwrite the HTTP request header sent by the browser, and the original session ID is sent to the server, the original session can still be found by opening the browser again.

It is precisely because closing the browser does not cause the session to be deleted, forcing the server to set an expiration time for seesion, when the client last time to use the session more than the expiration time, the server can assume that the client has stopped the activity, The session is deleted to save storage space.

V. Understanding Javax.servlet.http.HttpSession

HttpSession is the Java platform for the implementation of the session mechanism specification, because it is only an interface, specific to each Web application Server provider, in addition to the specification support, there will still be some specifications do not specify the subtle differences. Here we demonstrate with Bea's WebLogic Server8.1 as an example.

First, Weblogic server provides a series of parameters to control its implementation of HttpSession, including switch options using cookies, switch options using URL rewriting, session persistence settings, session Expiration time settings, and various settings for cookies, such as setting the name of the cookie, the path, the domain, the lifetime of the cookie, and so on.

In general, the session is stored in memory, when the server process is stopped or restarted, the memory of the session will be emptied, if you set the session's persistence feature, the server will save the session to the hard disk, When the server process restarts or the information will be reused, the persistence methods supported by Weblogic server include file, database, client cookie save, and replication.

Replication is strictly not persisted, because the session is actually kept in memory, but the same information is copied to the server process within each cluster, so that even if a server process stops working, it can still get the session from other processes.

The cookie lifetime setting affects whether the cookie generated by the browser is a session cookie. The default is to use session cookies. Interested can use it to experiment with the misunderstanding we mentioned in section fourth.

The path to the cookie is a very important option for Web applications, and the default way that Weblogic server handles this option makes it significantly different from other servers. We'll have a discussion later.

Reference to Settings for session [5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

Six, HttpSession frequently asked questions

(In this section the meaning of the session is a mixture of ⑤ and ⑥)

1. When the session was created

A common misconception is that the session is created when there is client access, but the fact is that it is not created until a statement such as Httpservletrequest.getsession (true) is called by a server-side program, and note that if the JSP does not display the use < session= "False"%> closes the session, the JSP file is automatically added to the servlet when it is translated httpsession session = Httpservletrequest.getsession (true); This is also the origin of the hidden session object in JSP.

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

2. When the session is deleted

To synthesize the previous discussion, the session is removed in the following cases a. Program call Httpsession.invalidate (), or B. The time interval of the session ID sent by the client last received exceeds the timeout setting of the session; or C. The server process is stopped (non-persistent session)

3. How to delete the session when the browser is closed

Strictly speaking, do not do this. One way to do this is to use JavaScript code window.oncolose on all client pages to monitor the browser's closing action, and then send a request to the server to delete the session. But there is still nothing to do with the unconventional means of a browser crash or a forced kill process.

4. What's going on with a httpsessionlistener?

You can create such listener to monitor session creation and destruction events so that you can do some work when such events occur. Note that the session creation and destruction actions trigger listener, not the other way around. Similar to the httpsession-related listener and Httpsessionbindinglistener, Httpsessionactivationlistener and Httpsessionattributelistener.

5. Must the object stored in the session be serializable?

are not required. Requires that the object be serializable only for the session to be replicated in the cluster or to be persisted or, if necessary, the server can swap the session out of memory temporarily. Placing a non-serializable object in the session of the WebLogic server will receive a warning on the console. I used a iplanet version. If there are non-serializable objects in the session, it is strange to have a exception when the session is destroyed.

6, how to properly deal with the possibility of the client to prohibit cookies

Use URL overrides for all URLs, including hyperlinks, action for form, and redirected URLs, as described in [6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7, open two browser window access to the application will use the same session or a different session

Refer to the third section of the discussion of the cookie, for the session is to identify the ID, so different browsers, different window opening and different ways of storing cookies will have an impact on the answer to this question.

8, how to prevent users to open two browser window operation caused by the session confusion

This problem is similar to preventing multiple submissions of forms, which can be resolved by setting the client's token. is to generate a different ID on the server each time to return to the client, while saving in the session, the client submits the form must be returned to the server, the program first compares the returned ID with the value stored in the session is consistent, if inconsistent indicates that the operation has been submitted. You can refer to the section on presentation layer patterns in the "Java EE core model". Note that for Windows opened with JavaScript window.open, this ID is generally not set, or use a separate ID, in case the main window can not be manipulated, it is recommended not to window.open open the window to do the modification, so you can not set.

9, why to change the value of session in WebLogic server to re-call once Session.setvalue
The main purpose of this action is to indicate in the cluster environment that the value in the WebLogic server session has changed, and the new session value needs to be copied to the other server processes.

10. Why is the session missing?

Excluding the normal failure of the session, the possibility of the server itself should be minimal, although the author in Iplanet6sp1 plus a number of patches on the Solaris version has been encountered, the browser plug-in second, I have encountered 3721 plug-ins caused by the problem Theoretically, the firewall or proxy server may have problems with cookie processing.

Most of the reasons for this problem are procedural errors, and the most common is to access another application in one application. We'll discuss the issue in the next section.

VII. Cross-application session sharing

Often, a large project is divided into small projects to develop, in order to be able to not interfere with each small project as a separate Web application development, but in the end suddenly found that a few small projects need to share some information, or want to use the session to implement SSO ( Single sign on), the most natural requirement is to have access to each other's session in the session by saving the login user information.

However, according to the servlet specification, the scope of the session should be limited to the current application, the different applications are not able to access each other's session. Each application server adheres to this specification in real-world terms, but the details of the implementation may vary, so the methods for resolving cross-application session sharing vary.

First look at how Tomcat implements the session isolation between Web applications, and from the cookie path set by Tomcat, it differs from the cookie path set for different applications so that the session IDs used by different applications are different, So even if you access different applications in the same browser window, the session ID sent to the server can be different.

Based on this feature, we can speculate that the memory structure of the session in Tomcat is roughly the following.

The iplanet used by the author is also used in the same way, it is estimated that there is not much difference between SunOne and iplanet. For this kind of server, the solution of the idea is very simple, practical implementation is not difficult. Either allow all applications to share a session ID or let the application get the session ID of the other application.

There is an easy way to share a session ID in iplanet, which is to set the cookie path for each application to/(it should actually be/nasapp, which is equivalent to the root for the application).

/nasapp

It should be noted that the session of the operation sharing should follow some programming conventions, such as prefix the session attribute name with the application, so that setattribute ("name", "Neo") becomes setattribute (" App1.name "," Neo ") to prevent namespace collisions, resulting in overwriting each other.

There is no such a convenient option in Tomcat. On Tomcat version 3, we can also have some means to share the session. For tomcat of version 4 or more, the author has not found a simple method at present. Can only be aided by the power of third parties, such as the use of files, databases, JMS or client cookie,url parameters or hidden fields and other means.

Let's take a look at how WebLogic server handles the session.

From the screenshot, you can see that the path of the cookie that WebLogic server has set for all applications is/, does this mean that the session can be shared by default in WebLogic server? However, a small experiment proves that even if different applications use the same session, the individual applications can still access only those properties that they have set. This indicates that the memory structure of the session in WebLogic server may be as follows

For such a structure, it should be impossible to solve the problem of session sharing in the session mechanism itself. In addition to the power of third parties, such as the use of files, databases, JMS or client cookie,url parameters or hidden fields, there is a more convenient way, is to put an application session into the ServletContext, This allows another application to get a reference from the previous application from ServletContext. The sample code is as follows,

Application A

Context.setattribute ("AppA", session);

Application B

Contexta = Context.getcontext ("/appa");
HttpSession Sessiona = (HttpSession) contexta.getattribute ("AppA");

It is important to note that this usage is not portable because, depending on the Javadoc of ServletContext, the application server can be for security reasons for Context.getcontext ("/appa"); Passed in 8.1.

So why does WebLogic server have to set the cookie path for all applications to/? Originally for SSO, all applications that share this session can share authentication information. A simple experiment can prove this, modify the first login of the application's descriptor Weblogic.xml, change the cookie path to/appa access to another application will re-request login, even in turn, first access the cookie path to the application, Again to access the modified path of this, although no longer prompt to log on, but the user information is also lost. Note that the authentication method should use form when doing this experiment, because the browser and the Web server have other ways to deal with the Basic authentication method, the second request authentication is not through the session to realize. For details, see [7] secion 14.8 Authorization, you can modify the attached sample program to do these tests.

Viii. Summary

The session mechanism itself is not complex, but its implementation and configuration flexibility makes the specific situation complex and changeable. This also requires that we do not have a single experience or a particular browser, server experience as a universally applicable experience, but always need specific circumstances specific analysis.

Java Basics-A detailed explanation of the session