Cache Design of jdonframework

Cache Design of jdonframework

Embedded object Cache Design

Please refer to the following sectionCode:

Public class category extends model {

String ID;

Product product; // embedded contains a product object

}

The category model is embedded with the product model, which is an association.

Currently, the default cache provided by the jdon framework is flat, not embedded or tree-like (of course, jbosscache and other tree-like cache can also be used). Therefore, a modelb object (such as product) embedded into another modela object (such as category), The modelb object is cached together with the modela object by the jdon framework.

Assume that modela is already in the cache. If the client directly obtains modelb from the cache, it is not known that modelb is cached in modela (the annotation field is used in ejb3 object bean ), the cache may tell the client that no modelb is cached. Then the client may add a new modelb to the cache, so that the same ID may have two copies of modelb. When the client directly calls modelb to update the field, modelb contained in modela may not be updated (because modela has no field update ).

There are two solutions:

1. The most direct method is to manually clear the modela cache for update, or wait patiently for the modela cache to automatically update. To manually clear the cache, see the following chapter.

Note: The following will also cause inconsistency:

Read the database at the DaO layer. When modela is generated, you can directly read the database to fill modelb.

2. When designing modela and modelb related operation services, make sure that modelb points to the same one in both cases. For example:

To achieve this goal, as long as a cache decorator is added between the service layer and the DaO layer, any model object called by the service layer to the DaO layer will first pass the cache check, the modelb in modela saved in the cache is an empty object with only the primary key of modelb. In the getmodela method of the service layer, the modelb of modela is enriched and filled up. Based on the primary key of modelb in modela, first, go to the cache for query. If so, fill modelb in the cache into modelb of modela. This will be done.

For more information about the implementation, see the code of jivejdon 3.0. This is the case for Forum/forummessage.

Model Cache Usage

The jdon framework uses model caching in two ways:

The crud framework is used internally. If you use the crud function provided by the jdon framework, it has a built-in model cache and will immediately clear the cache.

Cacheinterceptor is used to cache the Interceptor. If you do not use the crud function of the jdon framework, the cache interceptor function will be activated. before obtaining a model from the service, first query whether the model exists in the current cache, if it is obtained from the cache. After changing the value in your model, you must manually clear the model cache. The cleanup method is as follows.

In addition to providingSingle Model CacheBesidesPersistence Layer Dao layer provides cache of query ConditionsFor example, if you perform a query based on the sorting of a field and other conditions, the query condition will be cached. In this way, if the same query condition exists next time, the query condition will be raised, some results related to meeting the query conditions (such as the total number of MET conditions) will also be proposed from the cache, saving the performance overhead of the database.

Manual access to cache

In general, the front-end presentation layer accesses a service in the service layer through the getservice method, and then obtains a model through the service. In this case, the cache interceptor of the jdon framework will automatically read from the cache first.

However, sometimes we need to obtain a model when coding the service layer. In this case, the cache interceptor of the jdon framework does not work. In this case, we may need to manually access the cache.

Because pojo of all service classes belongs to the internal container components of the jdon framework, it is actually a problem to access the container components in the container.

Use COM. jdon. container. finder. containercallback. At the same time, the pojo class of the Service uses containercallback as the construction parameter. When the pojo service class is registered to the container, the IOC feature of the container will find the pre-registered containercallback class.

Use containercallback to obtain the containerwrapper container instance, and then use the following method in containerwrapper:

Public object Lookup (string name );

Obtain the component instance registered in container. XML from the container. Each call of this method obtains the same instance, which is equivalent to the singleton method.

Modelmanager =

(Modelmanager) containerwrapper. Lookup ("modelmanager ");

The "modelmanager" string name is obtained from the container. XML query of the META-INF in the jdon Framework's jdonframework. jar package.

After obtaining modelmanager, we can basically access model-related functional arrangements, such as the getcache method of modelmanager.

In the next section, manually clear the cache, we use webapputil. getcomponentinstance obtains the modelmanager instance, which is a way to obtain container components from outside the container. This section describes how to obtain container components from the container, these two methods can be used flexibly according to our actual needs. The key is to clear where you need to trigger component calls?

Clear cache manually

Note: It is not necessary to manually clear the cache because objects in the cache have a period of existence, which is in the cache. as set in XML, after a period of time, the cache will automatically clear objects that are not used after the configured time, so that the data you modified will be reloaded from the database. If you cannot wait for these internal changes, you can handle them manually:

In either case, you need to manually clear the cache. First, in the DAO class of the persistent layer, you always need to manually clear the cache of the query condition, you only need to call the pageiteratorsolver upload ache method in the corresponding addition, deletion, and modification methods.

If you do not clear the cache, you can change a model data or add a new model data. You cannot see any changes during batch query: The model data is not modified; the new model is not displayed on the query page.

Second, the cache of a single model must be manually cleared without using the crud function of the jdon framework. If you use Versions later than 1.2.3, you can call COM. jdon. strutsutil. util. the clearmodelcache method of the modelutil class. This method is generally called before the background addition, deletion, and modification services are called in the action:

Note: The Key to manually clearing the model cache code is:

Modelmanager. removecache (keyValue );

KeyValue is the primary key value of the model. For example, if the user's primary key userid value is "2356", the keyValue is "2356 ". The simplified code is as follows:

// Obtain the modelmanager instance

Modelmanager = (modelmanager)
Webapputil. getcomponentinstance (componentkeys. model_manager, request );

Modelmanager. removecache (keyValue );

The above code is to access modelmanager outside the container. You can also obtain modelmanager by accessing components in the container in the previous section. The former is suitable for use at the presentation layer, and the latter is suitable for use at the service layer.

Finally, we will introduce how to clear all the caches and call the mongoache method of modelmanager (jdon framework 1.3 and later versions). In this way, the entire jdon framework cache is actually cleared.

The premise of the previous two cache cleanup methods is to first obtain modelmanager, especially when the service layer needs to clear the cache, it needs to obtain modelmanager by accessing components in the container. This is only applicable to the service layer composed of pojoservice, if we use the EJB Session Bean as the service layer, the current jdon framework container will not be loaded in the EJB container. Therefore, the container cannot be accessed in the Session Bean, modelmanager cannot be obtained. In this case, you can set the setmodified attribute of the model to true to indicate that the model has been modified and updated. When the presentation layer obtains the model, when the jdon framework cache interceptor intercepts, it finds that the model has been modified and will not be obtained from the cache.

Model has another method setcacheble. When it is set to false, the model will not be saved to the cache. If you do not want a model to be automatically stored in the cache by the framework, use this function. The difference between setcacheble and setmodified is that once the former is set to true, it is equivalent to a cache failure and will no longer be able to use the cache; the latter indicates that the current model has been modified, so that any attempt to read the model from the cache again (only once) will be blocked, in this way, you can directly obtain the data from the database and save it to the cache. In this way, the model data in the cache is fresh.

Understand the magic of the jdon framework setmodified. When you set the setmodified of a model to true, when you read the cache again, the jdon framework will ignore your reading and return a NULL; in this way, you can directly obtain the data from the database based on whether the returned data is null. After obtaining the data, do not forget to save it to the cache and overwrite the old data modified previously, make sure that fresh data is read from the cache each time.

= To sum up, there are two methods for manual cache clearing:

Directly operate on the cache and clear it from the cache;

If you cannot operate on the cache system, set the setmodified of the model.