Model-Oriented Software Architecture 3-resource management model Reading Notes (3)-eager Acquisition Model

2.3 eager acquisition mode

The eager acquisition (pre-acquisition) mode describes how to obtain resources at runtime by obtaining and Initializing Resources before actually using them.

 

1. Problem

Systems with soft real-time constraints must strictly specify when and how to obtain resources. Examples of such systems include key industrial systems and highly scalable Web applications.ProgramAnd even the graphical user interface (GUI) of the desktop application ). In each example, users of such systems make assumptions about system predictability, latency, and performance. However, if you execute any user-sent request, it will lead to expensive resource acquisition (such as dynamic acquisition of threads and memory), it may lead to unexpected time overhead. How can a system with soft real-time constraints obtain resources and still meet the constraints? To solve the problem, you need to pay attention to the following issues:

1) performance ). Resource users must obtain resources quickly.

2) predictability ). Resource users must be able to obtain resources in a predictable manner-each time they obtain resources, they should spend the same time.

3) initialization overhead ). You need to avoid Resource Initialization when the application is running.

4) stability ). Avoid resource depletion when the application is running.

5) Fairness ). The solution must be fair to other resource users who attempt to obtain resources.

 

2. Solution

Obtain the resource before using it. Before using resources (preferably at startup), the resource provider proxy has obtained resources from the resource provider in advance. Then, the resource is saved in an efficient container. When the resource provider proxy intercepts resource requests from resource users, it can access the capacity and return the requested resources.

You can use different policies to configure the time for obtaining resources. These policies should take into account different factors, such as when resources will be actually used, the number of resources, resource dependencies, and how long it will take to obtain resources. Possible options are obtained at system startup, or after the system is started, a specific time may be obtained after calculation. Regardless of the policy used, the target is to ensure that the resource is obtained and the resource is available before the resource is actually used.

 

3. Structure

The resource user obtains and uses the resource.

A resource is an entity such as memory or thread.

The provider proxy intercepts user requests for resources and immediately delivers the obtained resources to the resource users.

Resource providers manage and provide multiple resources.

 

 

4. Implementation

1) Select the resource to be obtained in advance. Determine the types of resources that need to be obtained in advance to ensure the predictability of the behavior of the entire system. Determine expensive resources, such as connections, memory, and threads. Obtaining such resources is the most unpredictable, so they are ideal candidates for pre-acquisition.

2) estimate the resource usage. Estimate how many resources a user can obtain in the lifecycle. If you do not know before, run the test run to measure the maximum resource usage. If you cannot predict resource usage, you can change it to a configurable parameter, which can be easily adjusted after deployment. Provide the operator with information about the actual usage of pre-acquired resources, such as logs.

3) implement provider proxy. The provider proxy is responsible for transparent integration of the eager acquisition mode. In actual design, you can include it in several ways, such as using the virtual proxy mode or interceptor mode. Resource users can obtain the provider Proxy from abstract factory. If transparency is not required, the resource user can directly obtain resources from the resource provider. In this case, the provider proxy is not required.

4) Implement containers. Implement a container, such as a hash table, to store pre-obtained resources. Capacity should support predictable search. For example, a hash table can provide a constant time for complex search.

5) determine the time policy. When the provider proxy obtains the resource selection policy in advance:

· When the system is started. Implement a hook to enableCodeIt is executed at startup. The advantage of this is that it does not affect the running behavior of the system, but this requires that you can predict the use of resources.

· Get it first at runtime. Use the reflection (image) mode to detect the system status that may cause resource users to obtain resources in the future. The advantage of preemptive behaviors is that they can more easily deal with the demand for resources. However, preemptive acquisition is costly for higher complexity and execution overhead for continuous monitoring of system status.

6) determine the initialization semantics. Determines how to initialize the obtained resources to avoid additional initialization overhead. For some resources, it is impossible for the resource provider to perform full initialization when obtaining the resource. In this case, you need to consider the initialization overhead during the runtime.

 

5. Conclusion

Advantages:

1) predictability ). Resource availability is predictable because requests from users to obtain resources are intercepted and processed instantly. This avoids the uncertain latency caused by the operating system when obtaining resources.

2) performance ). Because resources are available as needed, you can quickly obtain them at a specified time.

3) flexibility ). You can easily customize the resource to obtain the qualification. Intercepting users' Resource Acquisition requests allows the Provider Agent to strategically obtain resources, which is helpful to avoid side effects such as memory fragmentation.

4) Transparency ). Because resources are obtained in advance from the resource provider and do not require user intervention, this solution is transparent to users.

 

Disadvantages:

1) management responsibility ). Managing pre-acquired resources becomes an important aspect. Because not all resources are immediately associated with resource users, you need to manage them. You can use the caching mode and pooling mode to provide possible management solutions.

2) Static configuration ). The system becomes more static because the number of required resources must be estimated in advance. Excessive resource prefetch must be avoided to ensure fair use of resources and avoid resource depletion.

3) Over-acquisition ). The subsystem may obtain too many resources in advance, but it cannot actually use that much. This may result in unnecessary resource depletion. However, the correct resource acquisition policy helps solve this problem. You can also use the pooling mode to limit the resources you have obtained in advance.

4) Slow system startup (slow system start-up ). If the system needs to obtain a lot of resources during startup, obtaining them in advance may cause a long delay to the system. If the resource is obtained not at system startup, but later, there will be corresponding overhead.