A Novel Object Pool Service for Distributed Systems - Springer Link

A Novel Object Pool Service for Distributed Systems Samira Sadaoui and Nima Sharifimehr Department of Computer Science, University of Regina, Regina, SK Canada S4S 0A2 {sadaouis, sharifin}@cs.uregina.ca

Abstract. Efficient resource management is a great concern for many enterprise developers. One of the most important resources that should be carefully managed is the amount of memory consumed by applications. This paper proposes a novel distributed memory management framework, namely Distributed Object Pool Service (DOPS) which efficiently manages the lifecycle of entity objects in distributed systems. The generality and scalability of DOPS makes it reusable for any commercially distributed middleware, such as CORBA and COM+. In addition, since there is no absolute proper configuration to be used efficiently for object pools of any software system, we offer a workload simulator which simulates target systems in order to find the appropriate configuration for them. Using our workload simulator, we conduct several experimental tests using CORBA. These experimentations demonstrate the effectiveness of DOPS including the positive affect of dynamic sizing of object pools and the productivity of preparing fine-granularity configuration facilities. Keywords: Memory Management, Object Pooling, CORBA, Workload Simulator.

1 Introduction Object pooling is an important aspect in the design and development of distributed object-oriented systems. Two different categories of distributed objects exist: persistent and transient. Persistent objects are stateful objects whose lifecycles are longer than of their container (i.e. process or thread) that creates them. In contrast, the lifecycle of transient objects is limited by the scope of their container. So, the internal state of persistent objects should be stored in persistent object storages (i.e. ODBMS, File System). However, retrieving objects from persistent storages is a time consuming process that dramatically reduces system performance. Thus, it is better to keep a copy of all persistent objects in memory. But in enterprise systems which have billions of persistent objects, this scenario will not work because of the memory limitation. Hence, the primary goal of object pooling is to improve the performance by keeping a limited number of objects with more access probabilities in memory. Swapping useless objects from the memory is not a new idea. For instance, paging systems have been widely used at the memory manager unit of operating systems [7]. But, there are too many factors that differentiate the paging systems from object pooling in distributed object-based applications. For example, in paging systems, there is a unified behavior to all replaceable pages, while object pooling systems have access to meta-knowledge about their objects. Also, paging systems consider the pages as dumb R. Meersman, Z. Tari et al. (Eds.): OTM 2006, LNCS 4276, pp. 1757 – 1771, 2006. © Springer-Verlag Berlin Heidelberg 2006

1758

S. Sadaoui and N. Sharifimehr

objects that can not influence their lifecycle, but on higher level of abstraction, in object pooling systems, objects have the processing power. The differences originate from the more abstract concepts involved in object technology. So, we use the object pooling approach, which considers object-orientation abstract concepts, to sweep objects from memory. There are many research projects and commercial products such as Oracle JOC [11], JBossCache [12] and Apache JCS [13] which provide object pool facilities for available middlewares. However, all of them are middleware-dependent and also they do not provide sufficient flexibility and reusability to be used by different software systems. The main issue that these products do not address is finegranularity configuration possibility. Beside these products, there are some design patterns such as Object Pool [3], Evictor [5], Lazy Acquisition [1] and Leasing [2] which can be used together to build an object pooling service. However, there is no integrated framework pattern to prepare a detailed architecture for object pooling service. Also they do not address any adaptive facility to change the behavior of object pooling when dealing with the dynamic nature of software systems. On the other hand, none of the existing solutions provides a facility to help figuring out an appropriate configuration for a specific software system. Distributed reference counting approach [15] is another solution to sweep distributed objects from memory. However, this solution comparing to object pooling approach suffers from the following flaws: (1) no limitation is applied on the number of available objects in the memory; (2) probable frequent accesses to an object after releasing all of its references are neglected; (3) broadcasting reference management messages forces additional network traffic; (4) erroneously written client-side code result in the failure of solution applicability. According to these flaws, using distributed reference counting is not recommended in practice. On contrary, object pooling not only does not involve the flaws mentioned above but also reduces the costs of development and maintenance through its client transparency. Considering the problems above, in this paper we introduce a novel framework for object pooling named Distributed Object Pooling Service (DOPS). DOPS offers an applicable and efficient solution to prepare a middleware-independent object pooling service. Also, it offers an adaptive approach to automatically figure out the optimum size of object pools. Although some configurations should be done manually, we provide a workload simulator that allows us acquiring the most appropriate configuration for any specific system. We have fully implemented DOPS with Microsoft Visual C++ 6.0 (the whole software contains 64 classes and 10,000 lines of code) and we have conducted several experimentations to demonstrate the effectiveness of DOPS in practice. The remainder of this paper is organized as follows. Section 2 describes the overall architecture and design criteria of DOPS. Section 3 explores the facilities of our proposed framework considering our workload simulator. Section 4 illustrates the results of workload simulations that evaluate the performance of DOPS. Finally, Section 5 concludes the paper with some future directions.

2 DOPS Design 2.1 DOPS Architecture As shown in Fig. 1, DOPS comprises seven major components: (1) a DOPS Connector which offers a connector interface to distributed middlewares; (2) a Statistics Manager

A Novel Object Pool Service for Distributed Systems

1759

which gathers statistical data about incoming requests and pools activities; (3) a Performance Monitor which uses collected data by the Statistic Manager to show the throughput of DOPS; (4) a Pool Container which manages the containing object pools and dispatches the incoming requests to them. Also, it fetches objects to related object pools whenever it can not find the required objects in its object pools; (5) an Intelligent Pool Container Manager (IPCM) which is responsible to figure out the appropriate size of each object pool existing in the pool container; (6) a Reap Manager which is responsible to determine victim objects that should be thrown away from each object pool; (7) an Eviction Signal Generator which sends activation commands to the Reap Manager.

Statistics Manager

IPCM

Object Request Pool Container

DOPS

Eviction Signal Generator

Reap Manager

DBMS

Object Request

DBMS

DOPS Connector

DBMS

Performance Monitor

Fig. 1. DOPS Architecture

According to the architecture above, whenever a middleware directs an object request to DOPS, at first it goes through the DOPS Connector. This latter assures that all the incoming requests conform to the expected request format of DOPS. Then, DOPS Connector sends the object request to the Pool Container and also updates the statistical data about incoming requests. When the Pool Container receives the object request, at first it determines the target object pool. Later, it searches the target object pool to find the required object to perform the request. If it does not find that object inside the target object pool, it will fetch the object from associated persistence storage (i.e. DBMS, File system) to the related object pool. Then, the Pool Container returns a reference to that object. Consequently, the middleware calls the request on the object and releases the object reference. Since, the capacity of the Pool Container is fixed and limited, the Pool Container restricts the size of each object pool. The Pool Container uses IPCM to figure out the appropriate size of each object pool. On the other hand, whenever the Eviction Signal Generator sends activation signals to the Reap Manager, this latter process the signals and starts evacuation of the associated object pools to meet their allowed size by the Pool Container. 2.2 DOPS Design Criteria DOPS Connector. Integration of distributed middlewares into DOPS is an important issue that we address using a connector interface that includes two methods: (1)

1760


GetPooledObject method which returns a reference to the requested object and it is used to access an object registered in DOPS; (2) ReleasePooledObject method which has to be called by the middleware to release the acquired reference when processing of the object request is complete. This interface allows any distributed middleware which provide message profiling or general proxies to be integrated into DOPS. For example, here we explain the integration of CORBA [15] into DOPS. There is a component in CORBA namely POA which is responsible for managing the mapping between CORBA objects (or remote object references located on the client-side) and servants (or concrete objects located on the server-side). POA can be configured in such a way to perform this mapping through custom Servant Managers. POA supports two different kinds of Servant Managers: Servant Activator and Servant Locator. However, the integration into DOPS is only possible through servant locators, because a Servant Locator is responsible for supplying a servant for a CORBA object each time that a client makes a request on that object. Hence, this kind of Servant Manager is appropriate for connecting CORBA to DOPS. The Servant Locator interface has a pair of methods as follows: (1) preinvoke method which is called when the POA receives a request for an object. This method is called to acquire an appropriate servant for the requested object; (2) postinvoke method which is called when the processing of the object request is complete. Calling this method allows the implementation of Servant Locator to dispose of the servant when processing of the object request is complete.

POA preInvoke()

DOPS

GetPooledObject()

Operation() postInvoke()

CORBA object

ReleasePooledObject()

Reference to object

Connector

Object Request

Servant Locator

Concrete object

Fig. 2. CORBA integration into DOPS

Hence, there is a straight approach to integrate a servant locator to DOPS connector. Within preInvoke method of the servant locator, we should return the object acquired through calling GetPooledObject method of DOPS connector. Also within postInvoke method of the Servant Locator, we should call the ReleasePooledObject method of DOPS connector to release the acquired object reference (cf. Fig. 2). Pool Container. Pool Container manages the containing object pools and dispatches the incoming requests to them. Also, it fetches objects to related object pools whenever it


1761

can not find the required objects in its object pools. We should force objects that want to register in pools to implement certain interfaces with the following capabilities: • Diverse data storages and retrieval mechanisms can be used by objects. So, Pool Container is independent from persistence services or data storages that different objects use. • Integrated reference counting is prepared. So, Pool Container uses local reference counting mechanism that manages the lifecycle of concrete objects independent from any middleware. • The objects of pools can interfere in reaping activities and help to make correct decisions about their eviction as victims. So, Pool Container considers the consultation with candidate objects as victims to make correct decisions during the eviction process. Since Pool Container contains a number of object pools, it has to share the available memory capacity efficiently. Hence, we have to consider the variable size of pools during the design of this container. Also, we connect Pool Container to a component namely IPCM to figure out the appropriate size of each pool during the life cycle of the container. IPCM. In order to restrict the size of each pool and select it optimally, we design IPCM. IPCM assumes that all pools are inserted in a common container with a specified size. So, the total size of pools will be restricted to an upper bound which is the size of their container. The size of the pool container must be configured manually with respect to the availability of memory resources. However, the size of each pool is determined through IPCM. This approach monitors two parameters for each pool: activity ratio and hit ratio. Hence, IPCM is a feedback-based approach that uses activity ratio of each pool to make better decisions. Consequently, using the values of these parameters, an optimal size for each pool can be figured out. Considering both activity ratio and hit ratio, an acceptable total hit ratio for the pool container is gained but also the occurrence of starvation for each pool can be prevented. We define the activity ratio of a pool as follows1:

ARPooli (t ) =

PTIRPool i (t ) . CTIR (t )

Where: •

ARPooli (t ) is the activity ratio of i'th pool. • PTIRPooli (t ) is the total incoming requests on i'th pool. • CTIR (t ) is the container's total incoming requests.

And the hit ratio of a pool is defined as follows:

HRPooli (t ) = 1

PTHNPooli (t ) . PTIRPooli (t )

All equations explaining IPCM are based on t which shows time. So, the dynamic behavior of IPCM comes from this parameter.

1762


Where: •

HRPooli (t ) is the hit ratio of i-th pool. • PTHNPooli (t ) is the total hit number of incoming requests on i-th pool. • PTIRPooli (t ) is the total incoming requests on i-th pool. To determine the size of each pool according to above parameters, IPCM considers the following points: (1) Decrease the size of pools with lower activity ratios; (2) Increase the size of pools with lower hit ratios. So regarding these points, we create the following mathematical equation to figure out the size of each pool:

basesizePool i (t ) = ARPooli (t ) * C − HRPool i (t ) * ARPool i (t ) * C. Where C is the total size of the pool container. However, if we calculate the size of each pool with the equation above, the summation of sizes will be less than the total size of the pool container. Hence, to prevent wasting the available space of the pool container, we divide the remaining capacity equally between all pools as follows:

⎛ N ⎞ sizePool i (t ) = basesizePo ol i (t ) + ⎜⎜ ∑ HRPool j (t ) * ARPool j (t ) * C ⎟⎟ N ⎝ j =1 ⎠ Where N is the number of pools existing in the pool container. Reap Manager. Reap Manager contains different reap strategies that apply object replacement policies on associated object pools. In fact, there is a one to one mapping between reap strategies and object pools. This one to one mapping structure prepares precise configuration capability for each object pool. Since, the sequence of callings on each object pool is different, no single strategy works best. Therefore, we provide such a design that allows us to associate each object pool with an appropriate reap strategy. Whenever a reap strategy receives an activation signal from Eviction Signal Generator, it explores its associated object pool to find victim objects. Then, victim objects are thrown away to prepare free space in the object pool for loading new objects. Each strategy must satisfy the following properties: • Use simple and fast explorative techniques to find victim objects. • Select optimum objects as victims in such a way to increase the throughput. Some of the classic approaches which are used as reaping strategies are: Least Recently Used (LRU) [7], Most Recently Used (MRU) [7], oldest object [4] and object lease [2]. However, sizes of objects in each object pool are different and also the costs of loading those objects to object pools are not the same. Consequently, we better use cost-aware approaches such as greedy-dual-size [14] algorithm. But, using cost-aware approaches is not necessary for those kinds of object pools which contain objects with the same size and load cost. Thus, we must consider the following points to choose an appropriate reaping strategy for each object pool: • The size of objects which are loaded to the given object pool. • The cost of loading different objects to the given object pool. • The sequence of callings on different objects of the given object pool.


1763

Choosing victims from working sets of a pool causes frequent load/unload actions and hence decreases the performance of the pool. To select optimum victims, the reaping strategies at first determine the working sets. Afterwards the selection is performed among objects which do not exist in those sets. To determine the working sets, intelligent approaches are used. One of the most applicable approaches is Markov Model [6] which is also used in speech recognition and data compression techniques. Using pool’s Markov Model, eviction policies can find out which objects or group of them are probable to be needed. Using this information, eviction policies can determine the working sets. And as a result, selecting victims from those determined working sets can be avoided. On the other hand, prefetching objects to pools is possible through anticipation. Since there is not any absolute proper reaping strategy to be used efficiently in the pools of any software system, we emphasize the simulation of target systems through the workload simulator that we define and implement. Eviction Signal Generator. Eviction Signal Generator schedules the Reap Manager. It sends activation signals to the reaping strategies registered in the Reap Manager (cf. Fig. 3). Hence, Eviction Signal Generator associates different eviction triggers to existing reaping strategies. Important design criteria about this component are as follows: • Each eviction trigger can send eviction signals to one or more reap strategies. • Each eviction trigger can be a logical combination of other eviction triggers. The most famous strategies [4] to implement eviction triggers are as follows: • Explicit call: clients use explicit calls to send activation signal. • Connection closure: when a client’s connections to the server get closed, the server side connection managers send activation signals to the reap strategies. • Periodic eviction: the activation signals are sent in regular intervals to the reap strategies. • Object threshold: the activation signals are sent when the number of objects, available in pools, goes beyond a determined threshold. • Object activation: when incoming requests cause the pool container to load objects to an object pool, the activation signals are sent.

Fig. 3. Eviction Signal Generator Structure

1764


3 Workload Simulator Development As we have illustrated in the previous section, the appropriate configuration of DOPS involves many factors that can not easily be figured out mathematically. So, we need an instrument to figure out the most appropriate configuration. On the other hand, DOPS introduces an appropriate level of abstraction that makes it independent from the remote calling mechanisms and distributed middlewares. Consequently, DOPS offers a workload simulator that simulates remote callings and generates requests on objects according to different frequency functions and locality functions (cf. Fig. 4).

Workload Simulator

Domain Specific Application

1 2000

1 0000

8000

4000

2000

0 1

11

21

31

41

51

61

71

81

91

101 111 1 21 131 141 151 161 1 71 1 81 191 201 211 2 21 2 31 241 251 261 2 71 2 81 291

12 000

10 000

8 000

6 000

4 000

2 000

0 1

11

21

31

41

51

61 71

81

91 101 111 12 1 131 141 151 16 1 1 71 1 81 191 201 21 1 22 1 23 1 241 251 261 2 71 2 81 291

12 000

10 000

8 000

6 000

Request Generator

6000

DOPS Pool 1

Pool 3

Request Pool 2

4 000

2 000

0 1

11

21

31

41

51

61

71

81

91 1 01 111 121 1 31 141 151 16 1 171 181 19 1 201 211 22 1 23 1 241 25 1 26 1 271 281 29 1

RGU DBMS

DBMS

DBMS

Fig. 4. The Workload Simulator

We define Request Generation Units (RGU) (cf. Fig. 4) in the workload simulator to generate requests on each object pool. Each RGU includes the following identifiers: (1) a Request Frequency Function (RFF); (2) a Request Locality Function (RLF). The calling sequences of the workload simulator depend on the determined RFF for each RGU. In fact, each RFF determines the total incoming requests on the associated object pool according to a given time spot. Hence, the workload simulator uses RFFs to figure out the upper bound number of requests that should be sent to DOPS on a specific time spot. In order to simulate request localities, we define RLFs for each RGU. In fact, a RLF is a Probability Density Function (PDF). Hence, we generate random requests according to associated RLFs to object pools. We perform the process of random number generation from PDFs using the method described by Kronmal and Peterson in [10]. The workload simulator during the simulation time repeats the following steps on each registered RGU: (1) calculating the number of requests according to current time using RFF unit of RGU; (2) generating the calculated number of random requests using RLF unit of RGU; (3) sending generated requests to the object pool associated with RGU.


1765

According to the architecture shown in Fig. 4, we can change the configuration of the workload simulator and determine RFFs and RLFs. Afterwards the performance measurement of the system is prepared using DOPS monitors registered with each eviction policies. So, when the acquired performance measurements are not desirable, we can change the configuration of DOPS to achieve an acceptable level of performance. We should note that the workload simulator is used beside the real system and we do not remove the real system itself. It means that we replace the real middleware by a workload simulator. Therefore, after the determination of DOPS configuration through workload simulator, we can use the acquired configuration for the real system.

4 Performance Evaluations and Analysis Now we use our workload simulator to do some experimentation and evaluate the performance of DOPS. The goal of these experiments is to evaluate the effectiveness of the proposed techniques for sizing multiple object pools dynamically and using separate replacement strategies for each object pool. We evaluate cases with different number of object pools. However, for more readability, we just show the test cases with three object pools here. 4.1 Experimental Setup and Evaluation Criterion We use a machine equipped with one 1.7 GHz PIV processor, 1GB of RAM. Also we use MSSQL Server 2000 as the backend DBMS running on MS windows 2000. We develop an application with Microsoft Visual C++ 6.0 containing 20 entity classes which each of them only maps to one table in the database. Also, all of the objects instantiated from the same class have the same size. Consequently, through the interfaces offered by DOPS, we connect our application, which uses IONA/Orbacus 4.0.5 (a commercial implementation of CORBA) as its middleware, to DOPS. 4.2 Effectiveness of Using Multiple Replacement Strategies Here we demonstrate that why using one global replacement strategy for all object pools is not a satisfactory solution. In other words, we prove that using a separate replacement strategy for each object pool can result in better throughputs. As a test case, we simulate a system containing two object pools, Poo1 and Pool2, with the following RLFs: • localityPool1(x) =

(2 × x − 1) , x ∈ [1, N ] N2

This RLF is an Increasing Density Function (IDF). It means that the simulator makes requests on objects which are used longer time ago with higher probability. • localityPool2(x) = localityPool1(N – x + 1) , x ∈ 1, N This RLF is a Decreasing Density Function (DDF). It means that the simulator makes requests on objects which are used recently with higher probability.

[

]

1766

S. Sadaoui and N. Sharifimehr 120

120

100

100

80

80

60

60

40

40

20

20

0

0 0

100

200

300

400

500

600

700

800

900

1000

1100

(a) Pool1

0

100

200

300

400

500

600

700

800

900

1000

1100

(b) Pool2

Fig. 5. Scatter presentation of random requests generated according to associated request locality functions with object pools. Diagram (a) shows the requests made on Pool1 and Diagram (b) requests made on Pool2.

We suppose that the number of associated objects with each pool, which is denoted by N in equations above, is equal. Then, we configure the workload simulator to make requests on each object pool according to given request locality functions. The requests made by the simulator on both of object pools when N = 100 is shown in Fig. 5. In Fig. 5(a), the requests made on Pool1 have a high density on objects which are used long time ago. Also, we can observe in Fig. 5(b) that the requests made on Pool2 have a high density on objects used recently. Afterwards, we measure the throughput of each object pool while we associate them with two different replacement strategies: LRU and MRU. As illuminated in Fig. 6(a), the throughput of Pool1 when it uses LRU is better. Also Fig. 6(b) shows that Pool2 gains better throughput when it uses MRU. Hence, this test case shows that if we use separate replacement strategies, through facilities provided by DOPS, we acquire better throughput comparing the case when we use only one global replacement strategy.

(a) Pool1

(b) Pool2

Fig. 6. Throughput of each object pool for two replacement strategies: LRU and MRU. Diagram (a) shows the hit ratios of Pool1 and Diagram (b) the hit ratios of Pool2.

4.3 Evaluation of IPCM Performance To experiment the performance of IPCM with respect to existing approaches, we use the workload simulator. Our test includes two experimental variables: the frequency


1767

of callings on each pool, and the locality of incoming requests for each pool. So, we simulate a specific system with the following properties as shown in Fig. 7: • We create three different object pools in the pool container 2. • We determine frequency of incoming requests for each pool through a function based on time spots: o PTIRPool1(t) = A* ( sin( t ) + 1 ). o PTIRPool2(t) = B * ( sin( t + pi / 2 ) + 1 ). o PTIRPool3(t) = C. In fact, we choose two types of frequency functions: sinus form (which exhibits variable frequency of incoming requests on different time spots) and constant form (which shows constant frequency of incoming requests in all time spots). There are many other types of frequency functions that can be used in this experiment. However, they are mainly combinations between sinus and constant forms. A, B and C are the peak of request loads assigned to the pools. From now on, we call these variables calling frequency variables. So, through the assignment of different values to calling frequency variables, we simulate different workloads on each pool. • We generate incoming requests on each pool according to a PDF. Each PDF exhibits the probability of making a call on a specific object of a given pool after a specific time. So, we provide each pool with a separate PDF, which is based on x that shows the place of objects in a sorted list according to their last access time. This PDF is used to simulate different request localities for each pool: o localityPool1(x) = D. o localityPool2(x) = E. o localityPool3(x) = F. D, E and F are PDF type variables that can accept one of the following values: IDF, DDF, and Uniform Density Function (UDF). From now on, we call these variables request locality variables. So, we assign different PDFs to these request locality variables to simulate different request localities on object pools. So, we break down our two experimental variables to 6 new ones (A, B, C, D, E, and F) introduced in the properties of the simulated system above. To compare IPCM to other approaches, we consider different values of these variables. Then we start the simulation to figure out the throughput of the system using each approach. Here, we compare IPCM to the following approaches which can be used for determination of the size of each pool: • Static approach: in this approach, the total capacity of pool container is divided equally without caring about activity ratio and hit ratio. So, the size of each pool is calculated through the following equation:

sizePooli (t ) = C N . 2

We evaluated cases with different number of object pools and achieved similar results, so we just show the case for three object pools here.

1768


PTIRPool2(t) = B*(sin(t + pi/2 ) + 1) , localityPool2(x) = E 12000

Incoming Requests Frequency on Pool2

10000

8000

6000

4000

2000

0 1

11

21 31

41 51

61

71 81

91 101 111 121 131 141 1 51 1 61 171 181 191 201 211 2 21 231 241 25 1 261 271 281 291

Pool 1

Pool 3

PTIRPool3(t) = C , localityPool3(x) = F 1 200 0

Pool Container

1 000 0

800 0

600 0

400 0

Pool 2

200 0

0 1

12000


11 21

31

41

51

61

71

81

9 1 1 01 1 11 12 1 131 141 1 51 161 1 71 1 81 19 1 201 211 2 21 231 24 1 251 26 1 271 281 2 91


10000

8000

6000

4000

2000

0 1

11 21 31 41

51

61

71

81

91 101 111 121 131 141 151 161 171 181 191 201 211 221 231 241 251 261 271 281 291

PTIRPool1(t) = A*(sin(t) + 1) , localityPool1(x) = D

Fig. 7. The conceptual diagram of the simulated system

(a)

(b)

(c)

(d)

Fig. 8. Results of the experiments (independent of request locality variables). Diagrams (a) and (b) show the simulation results for larger sample variances of calling frequency variables, and diagrams (c) and (d) show the results when the sample variance is smaller.


1769

• Activity-based approach: through this approach, the total capacity of pool container is divided according to activity ratio of each pool:

sizePooli (t ) = ARPooli (t ) N . At first, we assign UDF to all request locality variables. In this way, we figure out the result of comparison independently from request locality variables. The result of this phase of simulation for different values of variables A, B, and C is shown in Fig. 8, we show from the simulation outcomes that the larger the sample variance the better performance of IPCM comparing to the other approaches. As shown in Fig. 8 for all values of calling frequency variables with different sample variances, the static approach is the worst solution. On the other hand, IPCM’s performance is lower than activity-based approach (cf. Fig. 8(a) and Fig. 8(b)) when the sample variance of calling frequency variables is small. However, when their sample variance is larger, the performance of IPCM is close to activity-based approach (cf. Fig. 8(c) and Fig. 8(d)). However, in practice we can not ignore the request locality variables. So, in the next phase of experiment we must figure out the affect of assigning different values to the request locality variables. The result of this phase of simulation is shown in Fig. 9 activity-based approach is the worst solution and the IPCM is the best one. However, sometimes all approaches result in close hit ratios (cf. Fig. 10(a)). In fact, IPCM considers the satisfaction of all object pools at the same time. Static-based approach wastes the available capacity of container because it divides the container's capacity equally. Also, activity-based approach just improves the total hit ratio while it starves object pools with low activity ratios. Hence, we offer a detailed test case to show the throughput of each approach for each object pool separately. In Fig. 10(a) the total

Fig. 9. When we consider the locality parameters, the activity-based approach is the worst solution and the IPCM is the best one

1770


(a)

(b)

(c)

(d)

Fig. 10. Analysis of a test case with close total throughputs. Diagrams (a) shows the totals hit ratios for each approach, and diagram (b), (c) and (d) show the throughput of each pool separately.

throughput of all approaches are close together. However, IPCM acquires better throughputs for two object pools (cf. Fig. 10(b) and Fig. 10(c)) comparing to other approaches. While the other approaches only result in better throughput for one pool (cf. Fig. 10(d)). Generally, simulations for containers with more object pools show that IPCM results in better throughputs for more object pools when the total hit ratio of all approaches are close together. According to above experiments, using IPCM in systems with different calling frequency functions and high probability of the locality of incoming requests is profitable. Hence, enterprise complicated software systems are appropriate cases for applying DOPS architecture.

5 Conclusion and Prospects This paper has presented DOPS for object pooling in distributed object-oriented systems. It has showed that DOPS provides a flexible and reusable solution to triumph over memory management difficulties. DOPS is suitable for distributed middlewares which provide message profiling mechanisms and also use general proxies to access concrete objects existing in the server side.


1771

On focus of our future work is to making an integrated approach for object pool configuration. Using a central configuration repository, we can isolate the client code from the configuration mechanisms. Also the capability of using intelligent methods will be provided. For example, machine learning techniques can be used to find optimum configurations transparently and automatically. Other research directions include adding fault tolerance to DOPS through replication mechanisms. Concerning the different degrees of backup pools readiness [4], an applicable pattern will be provided. Another interesting issue to be addressed is applying concurrency controls on DOPS. DOPS builds object pools in the memory and separates the objects from the underlying transactional storages. This causes the concurrent access to shared objects without any concurrency management. So, ACID (Atomicity, Consistency, Isolation, Durability) [8] properties of transactions, especially consistency and integrity, will be missed. Consequently, providing locking mechanisms for DOPS is mandatory. Also DOPS can be used by agent-oriented middlewares [9] to manage the lifecycle of agents. However, yet there is no operational agent-oriented middlewares having proper message profiling facilities.

References 1. M. Kircher, Lazy Acquisition Pattern, Proceedings of the European Pattern Language of Programs Conference, Kloster Irsee, Germany, July 4-8, 2001 2. P. Jain and M. Kircher, Leasing Pattern, Proceedings of the Pattern Language of Programs Conference, Allerton Park, Illinois, USA, August 13-16, 2000 3. M. Grand, Patterns in Java - Object Pool, John Wiley & Sons,1998 4. D. Slama, J. Garbis and P. Russell, Enterprise CORBA, Prentice Hall, 1999 5. P. Jain, Evictor Pattern, Proceedings of the Pattern Language of Programs Conference, Allerton Park, Illinois, USA, 2002 6. D. Salomon, Data Compression: The Complete Reference, Springer, 2004 7. A. Tanenbaum, Modern Operating Systems, Prentice Hall, 2001 8. J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1993 9. A. Omicini, G. Rimassa, Towards Seamless Agent Middleware, Proceedings of the 13th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2004 10. Kronmal RA, Peterson AV Jr (1979a), On the Alias Method for Generating Random Variables from a Discrete Distribution, American Statistician, Vol. 33, No. 4, pp. 214-218 11. Oracle JOC 10.1.2 Tutorial, Oracle Technology Network, 2004 12. B. Ban and B. Wang, JBossCache Reference Manual V. 1.2, JBoss Inc., 2005 13. JCS v.1.2.7.3 Project Documentation, Apache Software Foundation, 2006 14. L. Cherkasova, Improving WWW Proxies Performance with Greedy-Dual-SizeFrequency Caching Policy, In HP Technical Report, Palo Alto, November 1998. 15. D I Bevan, Distributed garbage collection using reference counting, Volume II: Parallel Languages on PARLE: Parallel Architectures and Languages Europe, p.176-187, March 1987