Status object: Database replacement

Theedge recommendation []
Source: jdon
Author: banq, Banqiao Renren

This is a very important concept that is easy to ignore in practice. It is important because it is more important than a database. It is also the same reason that it is easy to be ignored. It is often replaced by the Database concept.

If you do not have the concept of state in your experience or experience, to the extreme, it is possible that your java system experience has not accumulated to a certain extent, and the State is that every JavaProgramProblems that developers will inevitably encounter after going deep into the java system.

In this article, I want to try to express two States: the active State object and the persistent state. The data in the database is only a kind of status
Long-term results, while Java Systems
During running, we are more likely to deal with the status of an activity. The status of this activity exists in the memory, rather than persistent to the hard disk. Of course, if needed, you can use the database/file to persist to the hard disk.
.

However, if you replace the status with the database data, it may lead to frequent access to the database, in addition, your system will become a poor system that is not object-oriented, tightly coupled, and scattered data blocks everywhere. Such a system is no better than the traditional two-layer structure! It will not embed Java in JSPCodeWhere is the pseudo-L3 system.

What is status?

As long as an object has a State, any object activity has its own state attribute, Class
The field attribute is very likely to be in the State. The domain model we often use is actually
If you do not have a deep understanding of the state of an object, you cannot really grasp the characteristics of the object system or the execution of the domain model.

For beginners, I often have questions about whether to put data in httpsession or request. In fact, the contact status has started. Once you get in touch with the status, you should be careful, because you may direct the demon with Memory leakage.

The time when the memory leak occurs depends on the lifecycle of your status and the number of concurrent accesses to the system.

The lifecycle of an object that contains the State. In a simple system, you only need to create an object through new, then it will rely on the JVM garbage collection mechanism to recycle its demise, but will it be so simple?

The danger of status also occurs in the multi-threaded environment. What should I do when multiple threads write operations on the status in the same memory? If this status
Persistence in the database, we will rely on the powerful transaction mechanism provided by the database to prevent such concurrent deadlocks, but if it is in the memory, it is very difficult for you to do so, we should try to avoid concurrent access with such multithreading.
Singleton mode is very prone to this phenomenon. Therefore, in practice, Singleton mode must be avoided during J2EE development.

The Web Container or JSP/servlet we are exposed to is essentially a multi-thread, which many beginners do not know, because multi-thread programming is complex or difficult, therefore, upper-layer encapsulation such as JSP/servlet is available, but we use them
Multi-threaded programming.

The lifecycle and multi-thread concurrency make our simple object-oriented system extremely complex and difficult to grasp. From these two perspectives, I will give two ways of thinking.

Scope)

Scope refers to the activity cycle of the State, when the State object is created, and when it is destroyed.
However, if the State object has not been created or destroyed, you may fail to access the State object again, and the State lifecycle control may be scattered in various places of the running program, if it is not the same as the status Mode
For unified control, it is possible that the entire system is in crisis.

The State lifecycle is actually the object lifecycle, which is more detailed: it is the lifecycle of the domain model object. This is an unavoidable topic in a design concept driven by domain models, and the complexity of the practice of Domain Models is complicated here.

There are currently three types of status lifecycles in J2EE: Request/session and application,
A request is a request sent by each client. It is the most basic event activation unit in the J2EE system,
When the server releases a page to the client, this request ends. If our status is stored in the request, it means that before the request ends
You can perform operations on this state (object) at any stage of the request. (Mastering this principle is helpful for you to learn about struts and JSF)

If it is a session, it will always be related to the client. As long as it is any part of each request sent by the client, this State (object) can be operated.

If it is application, it means that this status is the global status of the current web project.

These three states exist in the form of saving the state in the memory, which is opposite to the persistence state. Memory activity status.

The shorter the lifecycle, the better. In this way, the state object can be automatically destroyed to avoid
Memory leakage in a large volume of traffic, but in a large volume of traffic, frequent object creation and destruction are performance-consuming.

Therefore, we may often use httpsession to save the status. At this time, you are very likely to cause memory leakage.
The idea of saving a lot of database data in httpsession on the jdon forum is quite dangerous, because once there are many concurrent users, there are quite a few httpsession packages.
The status is included, and there may be more references in the status, so the memory will soon be full, or the garbage collection mechanism is frequently started, causing the application system to pause or slow.

When you put the status into httpsession, didn't you consider manually eliminating it? You need to know all web containers
(Tomcat/WebLogic, etc.) will not automatically clear the State objects you may not need for you. If everyone only adds new elements, regardless of restructuring or management, the system will remain chaotic.
? In code, we solve this problem through refactoring and other structure/behavior patterns. What about status management during runtime?

The State management mode or object management mode solves this problem.

In this mode, you must manually manage the status in httpsession. For example
Httpsession sets up the maximum size of a State container. When this size is exceeded, you need to remove unused states from the container,
But what if the client accesses this status again during the session failure period? Then you may need to temporarily Save the status serialization to the hard disk and wait until the session expiration time reaches.
Deleting.

Is it troublesome?

Shortcuts include:
1. Try to save the status with httpsession as few as possible, which is also beneficial to the cluster environment. So where are these statuses? Using the application cache,

2.
The status management middleware is used. Currently, there are several options: EJB stateful beans; nanocontainer and other state-related micro containers. So can spring be used? No
This function, even in the spring container, cannot directly use the session state. It can only be implemented through threadlocal at the Thread level (sorry, you have to start back to ancient times.
), While the jdon framework can.

Next we will talk about the application status. In this range, an object status can be accessed by multiple users repeatedly. At this level, the status is similar to the data in the database, because the database can be used to replace this level of state, the deep Technology of putting the State into the cache is ignored by most beginners, and even the dependence on the database is generated.

Cache status

Although we save the status in the application, we still encounter the same session Status
The problem is solved by a dedicated cache middleware. Of course, in a multi-server cluster system, if a client stores the status in a server, so can I
In memory? The answer is yes, provided that you must use the distributed cache system.

Currently, the distributed cache system relies on the EJB server. When JBoss
5. When 2006 is completely decoupled and dissoluble, we can use the JBoss distributed cache system that originally only supports EJB to support our common JavaBeans (pojo ). This
At present, it may take some effort, because there is no unified pojo Component Interface Standard, and I believe it will be possible in the future.

If you don't want to spend any effort and it may be just a server, you can use a dual-core chip to improve performance, what if single-state cache is implemented? It is easy to use a cache product, such as Oscache, to save the settings in the application, or perform simple configuration in Web. xml.

However, you may encounter another problem: how to retrieve the one you want from the cached state of so many objects through the unique identifier? Trivial.

Is there a framework that helps you save the trouble? Of course, jdon framework is recommended, as long as the class containing the status (mainly domain model) inherits a specific class or interface (the interface is implemented in version 1.4) the class object will be cached or read from the cache at runtime, and you no longer need to take care of the cache, it is so simple.

Of course, jdon
The underlying cache of the framework can be replaced and used by your favorite cache products, because the jdon framework is based on IOC design, and the components are completely decoupled and thorough.
Solution, which can be replaced and replaced by configuration. If you do not understand this, you need to take a good look at the IOC model to bring us revolutionary new changes.

From the above, we can see that the complexity of Java lies in the fact that we need to imagine the runtime situation while coding. However, this kind of translation Lenovo has no profound practical skills and is difficult to accomplish smoothly.

Status management middleware

Since the development of the middleware era in J2EE, a considerable number of advanced middleware Products have provided general functions unrelated to specific applications. State management middleware has long existed, and EJB's stateful Session Bean is a representative.

A middleware should not only have a sound loose coupling design, but also a good dynamic design. For example, state management is a kind of dynamic design.

Of course, if you are modest, you should not only choose some frameworks or middleware with good static design, but also rely on some middleware with good dynamic operation management.

Whether it is ejb1.x/ejb2.x/ejb3.x. it should be better in State management. Of course ejb3.x has absorbed excellent static design concepts. However, due to the need for a specific server implementation process, there are some traps in this process, such as in-box problems.

Spring is undoubtedly a very good framework for static design. It has been tirelessly working on AOP and strives to explore a shortcut for dynamic operation management intervention from the AOP perspective. I believe there will be amazing results. Of course, this fine-grained AOP requires practice tests. Of course, it would be better if JDK 6.0 is integrated.

The jdon framework tries to strike a balance between the two currently, with both IOC and AOP excellent static design, although it is not as avant-garde as spring in AOP; however, it provides effective session and cache status management;

If you do not need the distributed multi-server cluster function of EJB, and are not a fan of AOP, it is undoubtedly convenient to use frameworks such as jdon framework.

Difficulties in status Design

Finally, I have to reiterate that it is not a matter of having a good state management framework that we can rest assured. The state design is actually a variable subject that every project must face, if the status is complex, you can use the status mode. Unfortunately, the status is not complex enough.

Whether the attributes and States of an object should be coupled or separated. There is no clear line between attributes and States. Let's take an example:

This forum Forum object has some field attributes, such as the Forum name, Forum description, and other related attributes, such as the Forum's
The last post; the post volume of the forum, the latter two seem to be forum fields, but they may change frequently and should belong to the status. What is the relationship between the status and the main object forum? Yes.
Should I create a status object separately if the fields of the latest post and the posting volume of the Forum are merged into the domain model of Forum? What is the basis for separation?

Of course, the reason for separation is that the object life cycle is different. We can immediately identify the lifecycles of the topics we are familiar with. What if we are not familiar with Domain Modeling?

Therefore, we already understand that the difficulty of state design is: how to create model objects in a granular manner, and then identify the dynamic state nature. This is a challenge in Domain Modeling practice.

Many people ask me: What do you mean by Domain Modeling, design patterns, and frameworks? Why are they Three Treasures of Java development and design? Or three typical knowledge points? I want to use this article to explain some features of Domain Modeling through the concept of state.

Currently, the four-color prototype archetype in MDA will help us better distinguish the attributes, states, and behaviors of classes. This is a software revolution that will bring about the next ten years.