An example of how Tomcat manages Session

Learned ConcurrentHashMap but don’t know how to apply it? I use Tomcat's Session but I don't know how it is implemented. How is the Session created and destroyed? Just read on and you’ll find out.

Session Structure

Without further ado, here are the pictures

Looking closely at the above figure, we can draw the following conclusions

• HttpSession is the interface class for operating Session in the JavaEE standard, so we actually operate the StandardSessionFacade class
• The data structure used by Session to save data is ConcurrentHashMap . As you can see in the figure, we have saved a msg in Session .

Why do we need to use ConcurrentHashMap ? The reason is that when processing an HTTP request, not only one thread will access the Session. Modern Web applications usually need to execute multiple requests simultaneously when accessing a page, and these requests may be executed simultaneously by different threads in the Web container at the same time. Therefore, if HashMap is used, it is easy to cause thread safety issues.

Let's first look at the HttpSession wrapper class.

StandardSessionFacade

In this class we can learn the practical application of the appearance pattern (Facde). Its definition is shown below.

public class StandardSessionFacade implements HttpSession

So how does this class implement the Session function? It is not difficult to see from the following code that this class is not a real implementation class of HttpSession, but a wrapper of the real HttpSession implementation class, exposing only the methods in the HttpSession interface, which is the facade mode in the design pattern.

 private final HttpSession session;
 public StandardSessionFacade(HttpSession session) {
 this.session = session;
 }

So why don't we just use the HttpSession implementation class?

According to Figure 1, we can know that the real implementation class of HttpSession is StandardSession . Assuming that some methods are defined in this class that should be called by Tomcat instead of by the program, then due to the Java type system we will be able to directly operate on this class, which will bring some unforeseen problems, as shown in the following code.

If we wrap StandardSession with another layer, an error will occur when the above code is executed. As shown in the figure below, a type conversion exception will be thrown, thus preventing illegal operations here.

Going further, can we access StandardSession directly without going through the facade class?

In fact, it is possible. We can get StandardSession through reflection mechanism, but you'd better know what you are doing. The code is as follows

 @GetMapping("/s")
 public String sessionTest(HttpSession httpSession) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {
 StandardSessionFacade session = (StandardSessionFacade) httpSession;
 Class targetClass = Class.forName(session.getClass().getName());

 //Modify visibility Field standardSessionField = targetClass.getDeclaredField("session");
 standardSessionField.setAccessible(true);
 //Get StandardSession standardSession = (StandardSession) standardSessionField.get(session);
 
 return standardSession.getManager().toString();
 }

StandardSession

The definition of this class is as follows

public class StandardSession implements 
HttpSession, Session, Serializable

Through its interface, we can see that in addition to the functions required by HttpSession in the JavaEE standard, this class also has serialization functions.

In Figure 1, we already know that StandardSession uses ConcurrentHashMap to save data, so next we will focus on the implementation of serialization and deserialization of StandardSession , as well as the function of the listener.

Serialization

Remember in the last section we obtained StandardSession through the reflection mechanism? Using the following code, we can directly observe what the deserialized StandardSession looks like.

 @GetMapping("/s")
 public void sessionTest(HttpSession httpSession, HttpServletResponse response) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException, IOException {
 StandardSessionFacade session = (StandardSessionFacade) httpSession;
 Class targetClass = Class.forName(session.getClass().getName());

 //Modify visibility Field standardSessionField = targetClass.getDeclaredField("session");
 standardSessionField.setAccessible(true);
 //Get StandardSession standardSession = (StandardSession) standardSessionField.get(session);
 
 //Save some data for observationstandardSession.setAttribute("msg","hello,world");
 standardSession.setAttribute("user","kesan");
 standardSession.setAttribute("password", "Like");
 standardSession.setAttribute("tel", 10086L);
 //Write the serialized result directly to the Http response ObjectOutputStream objectOutputStream = new ObjectOutputStream(response.getOutputStream());
 
 standardSession.writeObjectData(objectOutputStream);
 }

If nothing goes wrong, the browser accessing this interface will perform the download operation and finally get a file

Use WinHex to open and analyze. The figure shows the result after serialization, which is mainly a lot of separators, as well as type information and values, such as the standard information in the red box in the figure.

It is not recommended that you study how serialized files organize data, because it is not very meaningful.

If you are really interested suggest you read the following code org.apache.catalina.session.StandardSession.doWriteObject

Listeners

In the JavaEE standard, we can monitor Session changes by configuring HttpSessionAttributeListener , so how is it implemented in StandardSession ? If you understand the observer pattern, you probably already know the answer. Taking setAttribute as an example, after calling this method, the listener method will be called immediately in this thread for processing, which means that we should not perform operations that block for too long in the listener.

 public void setAttribute(String name, Object value, boolean notify) {
 //Omit irrelevant code//Get the event listener configured aboveObject listeners[] = context.getApplicationEventListeners();
 if (listeners == null) {
  return;
 }
 for (int i = 0; i < listeners.length; i++) {
  //Only HttpSessionAttributeListener can execute if (!(listeners[i] instanceof HttpSessionAttributeListener)) {
  continue;
  }
  HttpSessionAttributeListener listener = (HttpSessionAttributeListener) listeners[i];
  try {
  //Call the listener's processing method in the current thread if (unbound != null) {
   if (unbound != value || manager.getNotifyAttributeListenerOnUnchangedValue()) {
   //If the value of a key is modified, call the listener's attributeReplaced method context.fireContainerEvent("beforeSessionAttributeReplaced", listener);
   if (event == null) {
    event = new HttpSessionBindingEvent(getSession(), name, unbound);
   }
   listener.attributeReplaced(event);
   context.fireContainerEvent("afterSessionAttributeReplaced", listener);
   }
  } else {
   //If a new key is added, execute the attributeAdded method context.fireContainerEvent("beforeSessionAttributeAdded", listener);
   if (event == null) {
   event = new HttpSessionBindingEvent(getSession(), name, value);
   }
   listener.attributeAdded(event);
   context.fireContainerEvent("afterSessionAttributeAdded", listener);
  }
  } catch (Throwable t) {
  //Exception handling}
 }
 }

Session Life Cycle

How to save the session

After understanding the structure of Session, it is necessary to clarify when StandardSession is created and what points need to be paid attention to.

First, let's take a look at the StandardSession constructor, the code of which is as follows.

 public StandardSession(Manager manager) {
 //Call the constructor of the Object class, which has been called by default //Declare it again here, I don't know its purpose, maybe this class has a parent class before?
 super();
 
 this.manager = manager;
 //Whether to enable access count if (ACTIVITY_CHECK) {
  accessCount = new AtomicInteger();
 }
 }

When creating StandardSession , you must pass in a Manager object to associate it with this StandardSession , so we can turn our attention to Manager . The relationship between Manager and its subclasses is shown in the figure below.

We turn our attention to ManagerBase and find the following code.

protected Map<String, Session> sessions = new ConcurrentHashMap<>();

Session is a custom interface of Tomcat. StandardSession implements HttpSession and Session interfaces. This interface has richer functions but is not provided to programmers.

By looking up this property, we can find that all operations related to Session are implemented by operating sessions , so we can clearly see that the data structure that saves Session is ConcurrentHashMap .

How to create a session

So how is the Session created? I found the following method ManagerBase.creaeSession , and summarized its process as follows.

• Check if the number of sessions exceeds the limit, and throw an exception if so.
• Creating a StandardSession Object
• Set various required session properties (validity, maximum timeout, sessionId)
• Generate SessionId. Tomcat supports different SessionId algorithms. The SessionId generation algorithm used in my debugging process is LazySessionIdGenerator (this algorithm is different from other algorithms in that it does not load the random number array at the beginning, but loads it when it is used. The random array here is not an ordinary random array but SecureRandom. For related information, you can read the article of the big guy)
• Increase the session count. Since Tomcat's strategy is to only count the creation rate of 100 sessions, sessionCreationTiming is a linked list with a fixed size of 100 (100 elements with null values ​​at the beginning). Therefore, when new data is added to the linked list, the old data must be removed from the linked list to ensure its fixed size. The formula for calculating the session creation rate is as follows

(1000*60*counter)/(int)(now - oldest)
in

• now is the time when the statistical data is obtained System.currentTimeMillis()
• oldest is the time when the earliest session was created in the queue
• counter is the number of elements in the queue whose value is not null
• Since the rate is calculated per minute, we must multiply 1000 by 60 here (there are 60,000 milliseconds in a minute).

 public Session createSession(String sessionId) {
 // Check if the Session exceeds the limit, and if so, throw an exception if ((maxActiveSessions >= 0) &&
  (getActiveSessions() >= maxActiveSessions)) {
  rejectedSessions++;
  throw new TooManyActiveSessionsException(
   sm.getString("managerBase.createSession.ise"),
   maxActiveSessions);
 }

 //This method will create a StandardSession object Session session = createEmptySession();

 //Initialize the necessary attributes in Session session.setNew(true);
 //Is session available? session.setValid(true);
 //Creation time session.setCreationTime(System.currentTimeMillis());
 //Set the maximum session timeout session.setMaxInactiveInterval(getContext().getSessionTimeout() * 60);
 String id = sessionId;
 if (id == null) {
  id = generateSessionId();
 }
 session.setId(id);
 sessionCounter++;
 //Record the time when the session is created, which is used to count the creation rate of the session. //Similarly, there is ExpireRate, which is the expiration rate of the session. //Since other threads may operate on sessionCreationTiming, it is necessary to lock SessionTiming timing = new SessionTiming(session.getCreationTime(), 0);
 synchronized (sessionCreationTiming) {
  //sessionCreationTiming is LinkedList
  //Therefore poll will remove the data at the head of the linked list, which is the oldest data sessionCreationTiming.add(timing);
  sessionCreationTiming.poll();
 }
 return session;
 }

Destroying a Session

To destroy the Session, it is necessary to remove the Session from ConcurrentHashMap . Following the clues, we can find that the code for removing the session is as follows.

 @Override
 public void remove(Session session, boolean update) {
 // Check whether it is necessary to count the expired session information if (update) {
  long timeNow = System.currentTimeMillis();
  int timeAlive =
  (int) (timeNow - session.getCreationTimeInternal())/1000;
  updateSessionMaxAliveTime(timeAlive);
  expiredSessions.incrementAndGet();
  SessionTiming timing = new SessionTiming(timeNow, timeAlive);
  synchronized (sessionExpirationTiming) {
  sessionExpirationTiming.add(timing);
  sessionExpirationTiming.poll();
  }
 }
 //Remove session from Map if (session.getIdInternal() != null) {
  sessions.remove(session.getIdInternal());
 }
 }

Time of destruction

Active destruction

We can perform session destruction by calling HttpSession.invalidate() method. This method ultimately calls StandardSession.invalidate() method. The code is as follows. It can be seen that the key method to destroy session is StandardSession.expire()

 public void invalidate() {

 if (!isValidInternal())
  throw new IllegalStateException
  (sm.getString("standardSession.invalidate.ise"));

 // Cause this session to expire
 expire();
 }

The code of expire method is as follows

 @Override
 public void expire() {

 expire(true);

 }
 public void expire(boolean notify) {
  //Omit code//Remove session from ConcurrentHashMap manager.remove(this, true);
  //The omitted code is mainly to notify each listener of the session being destroyed}

Timeout destruction

In addition to active destruction, we can set an expiration time for the session. When the time is reached, the session will be actively destroyed by the background thread. We can set a shorter expiration time for the session, and then use JConsole to track its call stack to see which object and which thread executed the destruction operation.

As shown in the figure below, we set a 30-second timeout for the session.

Then we ManagerBase.remove

Put a breakpoint on the method and wait for 30 seconds, as shown below

Tomcat will start a background thread to periodically execute the backgroundProcess method of the subcomponent (provided that the subcomponent is managed by Tomcat and implements the Manager interface)

 @Override
 public void backgroundProcess() {
 count = (count + 1) % processExpiresFrequency;
 if (count == 0)
  processExpires();
 }

 public void processExpires() {

 long timeNow = System.currentTimeMillis();
 Session sessions[] = findSessions();
 int expireHere = 0 ;

 if(log.isDebugEnabled())
  log.debug("Start expire sessions " + getName() + " at " + timeNow + " sessioncount " + sessions.length);
 //From the JConsole diagram, we can see that isValid may cause the expire method to be called for (int i = 0; i < sessions.length; i++) {
  if (sessions[i]!=null && !sessions[i].isValid()) {
  expireHere++;
  }
 }
 long timeEnd = System.currentTimeMillis();
 if(log.isDebugEnabled())
  log.debug("End expire sessions " + getName() + " processingTime " + (timeEnd - timeNow) + " expired sessions: " + expireHere);
 processingTime += ( timeEnd - timeNow );

 }

We can take a look at the comments in the Manager.backgroundProcess interface. A brief translation is that backgroundProcess will be executed regularly by the container and can be used to perform session cleanup tasks, etc.

 /**
 * This method will be invoked by the context/container on a periodic
 * basis and allows the manager to implement
 * a method that executes periodic tasks, such as expiring sessions etc.
 */
 public void backgroundProcess();

Summarize

The data structure of Session is shown in the figure below. Simply put, ConcurrentHashMap is used to save Session , and Session uses ConcurrentHashMap to save key-value pairs. Its structure is shown in the figure below. .jpg

This means that instead of adding discrete data to the Session, it will be more performant to encapsulate the discrete data into an object as shown below.

//bad
httpSession.setAttribute("user","kesan");
httpSession.setAttribute("nickname","Like");
httpSession.setAttribute("sex","男");
....

//good
User kesan = userDao.getUser()
httpSession.setAttribute("user", kesan);

If you configure a listener for the Session, any changes to the Session will execute the listener method directly on the current thread, so it is best not to execute methods that may block in the listener .

Tomcat will start a background thread to periodically execute ManagerBase.backgroundProcess method to detect expired Sessions and destroy them.

Thought migration

Object Generation Rate Algorithm This algorithm design is quite interesting and can also be applied to other projects, so the following summary is made.

First, a linked list of fixed size (say 100) is generated and then filled with null elements. When a new object is created, the creation time is added to the end of the linked list (of course, it is the encapsulated object), and then the head node of the linked list is removed. At this time, the object removed is either a null node or the node that was first added to the linked list. When you want to calculate the object generation rate, count the number of non-null elements in the linked list and divide it by the difference between the current time and the time when the object was first created to get the rate. (Note the conversion of time units)

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.