11 pages

Please download to get full document.

View again

of 11
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
1 Pooling Michael Kircher, Prashant Jain {Michael.Kircher,Prashant.Jain}@mchp.siemens.de Corporate Technology, Siemens AG, Munich, Germany Copyright © 2002, Michael Kircher, Prashant Jain 10.05.2003 Pooling.fm Pooling 2 Pooling The Pooling pattern describes how expensive acquisition and release of resources can be avoided by recycling the resources no longer needed. Example Consider a web-based online catalog application that allows users to select and order one or more items. Assume tha
  10.05.2003 Pooling.fm 1 Copyright © 2002, Michael Kircher, Prashant Jain Pooling Michael Kircher, Prashant Jain {Michael.Kircher,Prashant.Jain}@mchp.siemens.de Corporate Technology, Siemens AG,Munich, Germany  10.05.2003 Pooling.fm Pooling 2 Copyright © 2002, Michael Kircher, Prashant Jain Pooling The Pooling pattern describes how expensive acquisition and release of resources can beavoided by recycling the resources no longer needed. Example Consider a web-based online catalog application that allows users to select and order oneor more items. Assume that the solution is implemented in Java using a three-tier architecture. The clients consist of web browsers that communicate with a Java Servletengine such as Tomcat. The business logic is implemented by one or more Java servletsthat execute in the Java Servlet Engine. The servlets themselves connect to a database usinga Java Database Connection (JDBC) interface. The following figure shows such a setupwith two servlets executing in the Servlet Engine and connecting to a database.Most of the web pages of the catalog are dynamically generated and depend upon thedatabase for their contents. For example, to get a list of available items in the catalog alongwith their pricing, a servlet connects to the database and executes a query. The servlet usesthe results of the query to generate the HTML page that is displayed to the user. Similarly,if a user makes a purchase and enters payment details via an HTML form, the servletconnects to the database and updates it.In order to execute SQL statements on the database, a servlet needs to obtain a connectionto the database. A trivial implementation would create a connection to the database onevery request of the servlet. However, such a solution can be very inefficient since it incursa delay in creating a connection to the database on every user request. In addition, such asolution is expensive since it results in potentially thousands of connections being createdwithin a short time period.An optimization to the solution could be to store a connection in the session context of theservlet engine. This would allow reuse of connection per session. Therefore, multiplerequests from a user belonging to the same session would use the same connection to thedatabase. However, an online catalog can potentially be accessed by hundreds of userssimultaneously. Therefore, even with this solution, to meet the requirements , a largenumber of database connections would be needed. Context Systems that continuously acquire and release resources of the same or similar type, andhave to fulfill high scalability and efficiency demands. Servlet Engine connections Database Servlet AServlet B  10.05.2003 Pooling.fm Pooling 3 Copyright © 2002, Michael Kircher, Prashant Jain Problem Many systems require fast and predictable access to resources. Such resources includenetwork connections, instances of objects, threads, and memory. Besides providing fastand predictable access to resources, systems also require that the solution scales across thenumber of resources used, as well as the number of resource users. Also, different user requests should experience very little variation in their access time. Thus, the acquisitiontime for resource r0 should not vary significantly from the acquisition time for resource r1 ,where r0 and r1 are resources of the same type.To solve the above mentioned problems the following forces need to be resolved:ã  Performance  —Wastage of CPU cycles in repetitious acquisition and release of resources should be avoided.ã  Predictability  —The acquisition time of a resource by a user should be predictable eventhough direct acquisition of the resource from the resource environment can beunpredictable.ã Simplicity  —The solution should be simple to minimize application complexity.ã Stability  —Repetitious acquisition and release of resources can also increase the risk of system instability. For example, repetitious acquisition and release of memory can leadto memory fragmentation. The solution should minimize system instability.ã  Reuse  —Unused resources should get reused to avoid overhead of re-acquisition.Patterns such as Eager Acquisition[Kirc02]and Lazy Acquisition [Kirc01] resolve only asub-set of these forces. For example, Eager Acquisition allows for predictable resourceacquisitions, whereas Lazy Acquisition focuses more on avoiding unnecessary acquisitionsof the resources.In summary, how can resource acquisition and access be made predictable while ensuringthat system performance and stability are not compromised? Solution Manage multiple instances of one type of resource in a pool. This pool of resources allowsfor reuse when resource users release resources they no longer need. The released resourcesare then put back into the pool.To increase efficiency, the resource pool eagerly acquires a static number of resources after creation. If the demand exceeds the available resources in the pool, it lazily acquires moreresources. To free unused resources several alternatives exist, such as those documented bythe Evictor [Jain02] pattern or the Leasing[JaKi00] pattern.When a resource is released and put back into the pool, it should be made anonymous bythe resource user or the pool, depending on the strategy used. Later, before the resource isreused, it needs to be re-initialized. If a resource is an object, providing a separateinitialization interface can be useful. The object ID, in many cases a pointer or a reference,is not used for identification by the resource user or the pool. Structure The following participants form the structure of the Pooling pattern:A resource user  acquires and uses resources.A resource is an entity such as memory or a thread.A resource pool  manages resources and returns them to resource users on acquisitionrequests.A resource environment, such as an operating system, owns and manages resourcesinitially.  10.05.2003 Pooling.fm Pooling 4 Copyright © 2002, Michael Kircher, Prashant JainThe following CRC cards describe the responsibilities and collaborations of the participantsThe interactions between the participants are shown in the following sketch. Dynamics The interaction between the participants varies slightly depending on whether the resource pool eagerly acquires resources at start-up or not.Assuming the pool does acquire the resources up front, subsequent acquisition requestsfrom resource users are served from those resources. Resource users release resources tothe resource pool when no longer needed. The resources are then recycled by the pool andreturned on new acquisition requests.A slightly more complex situation is described in the following sequence diagram, wherean acquisition request by a user leads to the acquisition of a resource from the resourceenvironment. Acquisition on demand is done because no pre-acquired resources areavailable. The resource user accesses and uses the resource. When no longer needed, theuser releases the resource back to the resource pool. The resource pool uses statistical data Class Resource Pool  Responsibility ãAcquires resources if necessary, eventuallyeagerly up front.ãRecycles unused resourcesreturned by resource users. Collaborator  ãResourceãResourceEnvironment Class Resource Environment  Responsibility ãOwns several resourcesinitially. Collaborator  ãResource Class Resource User   Responsibility ãAcquires and usesresources.ãReleases unused resourcesto the resource pool. Collaborator  ãResource Class Resource  Responsibility ãRepresents a reusableentity, such as memory or a thread.ãIs acquired from theresource environment bythe pool and used by the  resource user. Collaborator  Resource PoolResource acquirerelease EnvironmentResource User
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks