Shulou(Shulou.com)05/31 Report--

This article shows you how to analyze and solve the problem of missing partial attribute values of Session objects in Tomcat. The content is concise and easy to understand, which can definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Our recent Java project encountered a very strange problem after migrating from the development environment to the test environment-when storing and fetching a Java object into a SESSION session, some of the properties of the object were correct for a period of time after the SESSION session was created, but after a while, although the SESSION did not fail, the value of these properties became NULL. What's even weirder is that both properties that become NULL and attributes that haven't become NULL are the simplest String type variables, making it hard to see the difference between them.

In order to make the problem clear, let me give an example to illustrate it in detail. The class information we define is roughly shown in the following figure:

Where SessionBean is the object we are going to put into SESSION, and BaseBean is the parent class inherited by SessionBean. Whether in the development or test environment, SessionBean objects can access values without throwing any exceptions, but the properties are not necessarily: attributes an and b after the creation of SESSION, as long as the SESSION does not expire, they can always read their values normally; but the attribute c, which is only valid for a period of time soon after the creation of SESSION, if you take the value after a period of time, the value of attribute c will become NULL. Isn't it amazing that the value of the variable has changed without any operation?

[root cause of the problem]

I will not talk about the specific investigation process in the middle. Anyway, after a long period of analysis and investigation, the root of the problem has finally been found-BaseBean does not inherit the Serializable interface!

[cause analysis]

In combination with the above and my analysis of Tomcat server SESSION session management principles, I will explain to you why such a weird problem can occur without inheriting a serializable interface (Serializable).

First of all, when the SESSION is created, all the properties (a, b, c) in the SessionBean object can be written to the SESSION session normally, which is no problem. For the SESSION you just created, its contents are stored in the server's memory. If you read SEESION at this time, Tomcat will directly return the contents of memory to the caller, so the returned attribute values are correct.

Then, whether it's because the Tomcat takes up more memory than the threshold, or whether the Tomcat saves the SESSION live on a regular basis, it will cause the next operation-- to persist the SESSION session. In the process of writing data from memory to the hard disk, a very important question is involved: what format should the data be written to the hard disk, and how should it be changed into the corresponding format? This is-- serialization!

By looking at the code in the figure above, it is not difficult to find that the SessionBean object has implemented the Serializable interface, so during the process of saving the SessionBean object to disk, that is, when serializing the object, it will not report any errors, which is the root cause of the difficulty in locating the problem by tracking the error log. But because BaseBean, the base class of SessionBean, does not implement the Serializable interface, attribute c in BaseBean is not saved when serialized, and when deserialized, the value of attribute c becomes NULL. So it is not difficult to understand that the value we read has inexplicably become NULL.

[solution]

As for the solution, it is very simple, just add a Serializable interface to the base class BaseBean.

[reflection on the problem]

This question brings us two main reflections:

First, for a class saved in a SESSION session, make sure that the class and its parent class implement the Serializable interface, otherwise the properties in the class cannot be serialized.

Second, the validity of all uncertain values must be securely checked (defensive programming) before business logic operations. If I didn't "superfluous" this time, before the business logic, we checked the validity of this attribute c, which can basically be determined to be correct (because it is written into completely controllable and credible). This magical problem may not be discovered.

The above is how to analyze and solve the problem of missing partial attribute values of Session objects in Tomcat. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.