Solutions for capturing logout time-correct understanding of sessions in java)

Some time ago, I had to perform a function to capture user login and logout time. I checked a lot of information and made a lot of work.Test

And summarizes two sets of solutions, including further understanding of sessions.

The user's logon time is very good. After the user passes the verification, you can get the current system time record. If the system uses Acegi, you can write a class, inherit AuthenticationProcessingFilter from Acegi. java, and overwrite its onSuccessfulAuthentication method. Therefore, this method is an additional operation method that acegi performs when it successfully passes the user, in this method, you can record the current user ID, time, ip address, and so on.Logs

InformationDatabase

.

However, it is really troublesome to capture the user's logout time. First, you must know that http is a stateless connection protocol. When the user directly closes the browser or ends the process without logging out, the server cannot capture this event at all. No matter what Server occurs on the client, the user only obtains a sessionid from the server and stores it in the memory or cookie of the browser process, windows is widely used on the Internet. onunload () and other js methods to capture user logout events are actually not available, because users can directly kill the process or open the link in the new window page, and then close the original window, at this time, the browser event is captured through js and a request is sent to the server, but the user has not actually left the system, but has switched to a browser to browse the page. In addition, session expiration is used for capturing, but there are only two possibilities for session death during normal system operation:

1. The session owner (client browser) has no response or request within MaxInactiveInterval.
2. the invalidate () method is called to force the disadvantage. When the user closes the browser, it indicates that the session will no longer send requests to the server, and the server will not call its invalidate () method for no reason, in this way, the session will be destroyed only after time-out. If the MaxInactiveInterval of the session is set to-1, the session will survive until the server is closed.

Therefore, the session cannot reflect the user's activity status, and the browser closing event cannot completely determine that the user must have exited the system.

How can we get the logout time? In fact, we can only lower our expectations. We have been discussing with the boss for a long time. Finally, only two solutions can work, as shown below.

I. Changing the performance accuracy is also my final solution. We can get the user logon time accurately, and we can get the approximate time for logout, without being too precise, after all, the system is not very confidential. The session listener is used for implementation. The write class inherits HttpSessionListener and implements its public void sessionDestroyed (HttpSessionEvent arg0) and public void sessionCreated (HttpSessionEvent arg0) methods, when a user's session fails, the sessionDestroyed method is used. The current time obtained in the sessionDestroyed method is the approximate logout time of the user, provided that the system session expiration time cannot be set too long, otherwise, the error will be too big, and it will be about half an hour.

2. For performance with precision, pages of the B/S system generally carry headers, foot pages, or frame-type pages, in this way, We can insert a hidden IFRAME or code block in the public header or main frame page. Write a js method, window. setinterval () and so on, send an empty request to the server every short period of time (assumed as 2 minutes). The purpose is to let the server know that the client is still on my page, either way. After the Server accepts this request, it creates a map object (create a JavaBean class, which has two attributes: User ID and request time) and put. The current user ID is value, A convention is codenamed key, such as "userid", and the request time of another element is value. The same convention is codenamed key, such as "requesttime", and then the object is value, sessionid is the key, set an attribute to the session. When you receive another request, repeat the upper part of the request, so that the request time will be updated continuously. After doing this, you also need to add a scheduled job, traverse the session object every short period of time (assumed as 3 minutes), retrieve the userid and requesttime from the map or JavaBean, determine whether the time difference between the request time and the current time is greater than three minutes. If yes, it means that the user has not sent a request to the server, that is, no page is opened on the user end, and the user has left, record the last request time, that is, the user's logout time.

Not yetOthers

A better method. Now, this mechanism seems to be the only way to do this. Pay attention to the following:User Logon

The method for recording the logon time during success is not feasible when a large number of concurrent requests are required. During the login process of 50 or 100 concurrent users in a system of our project team today, the failure rate is very high, and the problem is the SQL transaction deadlock that occurs when logging on to the database and updating the maximum number of visitors, so the solution was changed later, when logging on, set the current time to value, sessionid to key, and set to session. When the session expires, the event is captured through httpsessionlistener, the user's logon time and current time are retrieved from the session and saved to the database. The latter is used as the logout time. the maximum number of visitors is also placed in the application, which improves the performance.

If you want to get the user's online time, note that because a browser process shares one session, all the tags in a browser also share one session, when a user logs on successfully, the current sessionid must be used to determine whether the user has logged on again. If yes, the current time should not be set to the session, the last storage logon time should be kept.

/*********** Next, introduce the classic online description, it is more conducive to understanding session and cookie ************/

Let's use several examples to describe the difference and connection between the cookie and session mechanism. I often went to a coffee shop and offered a free discount for five coffee cups. However, there is little chance of consuming five coffee cups at a time, in this case, you need to record the consumption quantity of a customer in some way. Imagine the following solutions:
1. The shop clerk is very good. He can remember the consumption quantity of each customer. As long as the customer enters the coffee shop, the clerk will know how to deal with it. This method is supported by the Protocol itself.
2. Send a card to the customer, which records the consumption quantity and generally has a validity period. For each consumption, if the customer shows this card, the current consumption will be associated with the previous or later consumption. This approach is to maintain the status on the client.
3. Send a membership card to the customer. No information except the card number is recorded. If the customer shows the card at each purchase, then the clerk finds the log corresponding to this card number in the store's record to add some consumption information. This approach is to maintain the status on the server side. Because the HTTP protocol is stateless and does not need to be stateful for various reasons, the next two solutions have become a realistic choice. Specifically, the cookie mechanism adopts the client-side persistence scheme, while the session mechanism uses the server-side

A scheme to maintain the status. At the same time, we also see that because the server-side persistence scheme also needs to save an identifier on the client, the session mechanism may need to use the cookie Mechanism to save the identifier, but in fact it still hasOthers

Select.