Cross-application Session sharing and session sharing

Cross-application Session sharing and session sharing
Cross-application Session sharingWhy Session Share?

In the daily development process, we often encounter a development scenario where a project is large and the development cycle is long, the product line or function should be divided into several sub-projects and allocated to different teams for development at the same time. This will shorten the development cycle, it also facilitates project maintenance. For example, for online Banking system development, the entire project may be split into sub-projects such as Login, Account, Banking, Cards, Insurance, and Investments.

After obtaining the project requirements, we will start our own work. in project development, we use Session to record the user status and save the interaction information between the client and the server. However, with the deepening of the project, we found that in different projects, in addition to maintaining the Session information of our project, we also need to share Session information between projects. For example, for the Insurance project, the Login project must provide the Customer's Customer Segment, and the Account project must provide the Customer's Account Information.

This leads to our topic today,How to share sessions between different applications deployed on the same server.

 

Project Demo:

To better understand the cross-application sharing of sessions, let's create the following three projects in Eclipse and create their respective Servlet Class and Configure, as shown below:

As shown above, we Put the Customer Segment and Customer Account in the Session objects of the Login and Account projects respectively, and tried to obtain them in the Insurance. We deploy these three projects to the Tomcat server at the same time and run LoginServlet/AccountServlet/InsuranceServlet in sequence. We hope to get the values set in the previous Session in Insurance, but we are very sorry, the console outputs null/null.

To better track the problem, we print out the current Session IDs in the Servlet Class of each project to see if they are the same. After compilation, redeploy our project and run Tomcat. The following output is displayed on the console:

From the output in the console above, we can see that the Tomat server assigns a Session for each project by default, so the Session content of other subitems cannot be obtained in the Insurance project. As shown in:

According to the Servlet specification, the scope of the Session should be limited to the current application. Different applications cannot access each other's Session. Each application server complies with this specification, but the implementation details may vary.

As shown in the preceding example, the Tomcat server assigns a Session object with a unique Session ID for each Application by default. However, not all servers follow this implementation. The company I work with uses IBM WebSphere Application Server, it uses the same Session ID for all Session objects distributed to applications deployed on the same server. However, when you try to obtain Session information across applications, you will find that the Session still fails. Although this type of server assigns the same Session ID to all Seesion objects, the generated Session object is closely related to the current Application, this ensures that the current application can only use its own Session object.Therefore, we cannot achieve cross-application sharing of sessions by starting with the Session ID.

 

How to share sessions across applications:

In the final analysis, the ultimate goal of cross-application Session sharing is to store the Session information in a place that everyone can access. Finally, each application obtains the shared Session information, we can achieve this through the following methods:

• Transfer Session information as URL parameters or hidden form fields to achieve Session sharing among applications (this approach is not recommended for security and convenience );
• Write Session information into the Cookie. Each application obtains the shared information from the Cookie. However, due to the Cookie's security and file size restrictions, you must carefully weigh the advantages and disadvantages when using this method;
• Write Session information to a specified file in a certain path of the server. Each application reads Session information from the file as needed. However, this method involves IO operations, which have a certain impact on the read/write speed and server overhead. In the context of high concurrent access, we also need to consider the problem of dirty Data Reading; if the file is lost, all applications cannot work normally.
• Write Session information to the database. Each application reads the corresponding Session information from the database as needed. This method is feasible, but database support needs to be introduced. In addition, frequent database read/write issues exist in High-concurrency access, which is still a test of performance;
• Write Session information to the server's JNDI to share sessions of each application;
• Put the Session of an application into the ServletContext object, and obtain the Session object of the previous application from ServletContext in another application to achieve Session sharing; the premise of using this method is that the cross-ServetContext is not disabled by the server.

The above lists some common methods for sharing sessions across applications in a single server instance, the purpose of sharing sessions across applications is to store Session information in a place where everyone can read and write. Which method should be used? Security, ease of operation, cost of use, and performance should be considered comprehensively.

 

 

 

I want to subscribe to sponsors and encourage the author to write better articles: