5.8 Object pooling

< Day Day Up >

Pooling Domino objects like sessions and views can help to significantly improve performance in a Portal environment. In a typical workplace we usually have more than one Domino Portlet on a page. In addition, it is usual for many users to have access to the same content. These circumstances can lead to limited-resource problems.

Limited resources can cause performance bottlenecks when there are not enough resources to meet clients' demands. For example, DIIOP sessions to Domino servers require non-trivial amounts of time to create and destroy. Often, in high-throughput scenarios, Portlets must wait for a session object to become available, creating a bottleneck in the flow of the application.

With object pooling, many Portlets can share a limited resource such as a session, using it only when they need it. In this way, the performance cost of creating and destroying the session is reduced.

Implementing an Object Pool can have the following advantages:

More scalable, resourceful

You can share Domino objects between multiple Portlets and reuse objects for users in the same user group.
Enables load balancing

DIIOP can't be used to access a cluster of Domino servers. A pool manager can manage sessions to multiple Domino servers at a time and allow load balancing and fail-over.
Thread safe

The Pool Manager is completely thread safe, meaning that it can be accessed safely from any number of threads-a situation that is common for Portlets.
Helps with DIIOP session time-out

DIIOP session time-out occurs when a session is idle longer than the DIIOP session time-out setting. By default this is 60 minutes. After this time the session and all it's associated objects become invalid.
Keeps Domino server healthy

It is good practice not to use remote Sessions for long periods of time. Recycling remote Session objects and all associated objects can help to keep the Domino server healthy, but Session recycling is tricky to manage.
Ease of use

You do not have to consider the possible state of a Domino object; you simply use the object. For example, if you want to retrieve data from a view, you do not need to know whether a session and database connection have been previously established, you can just retrieve our data.

Object pool

An object pool is a set of limited resources, such as sessions, that can be reserved for use by clients and then returned to the pool (for probable reuse) when the object is no longer needed. Reserving and returning pooled objects avoids the overhead of separately creating and destroying an object each time a client requests it. Multiple object pools can be used. For example, one object pool might contain session connection objects, and another pool might contain database or view objects.

Virtual and physical objects

Without object pooling, whenever a Portlet requests an object, a physical object is created, and is destroyed when no longer needed.

By contrast, when a Portlet uses object pooling, the request for a poolable object generates a virtual object instead. The virtual object supports all the methods of the requested object, but the Portlet sees only the virtual object.

When a Portlet calls an interface method from the virtual object, the virtual object's implementation requests a physical object from the pool and delegates the request to the physical object. When the request is complete, the Portlet returns the physical object to the Object Pool Manager for use by other virtual objects.

Client

In the context of object pooling, a client is the Portlet code that calls the Pool Manager. The Portlet requests objects, and the Object Pool Manager fulfills the requests or relays an error back to the calling Portlet.

Object Pool Manager

The Object Pool Manager is a service used by one or more Portlets. In response to clients' requests for objects, the Object Pool Manager controls one or more pools (for example, sessions and views) by reserving and releasing the objects in the pool. The Object Pool Manager performs the following tasks:

Queues virtual objects' requests for physical objects.
Marks physical objects as either free or reserved.
Attempts to create physical objects when necessary.
Destroys physical objects in a pool, based on idle time or usage limits.

Object pooling process

The object pooling process, illustrated in Figure 5-16, is as follows:

The Portlet calls an interface method on the virtual object.
The virtual object's implementation reserves a matching physical object from a named pool.
The method call is delegated to the physical object.
When the method call is completed, the physical object is returned to the appropriate pool for use by other virtual objects.

click to expand
Figure 5-16: Object pooling process

The Object Pool Manager uses a timer thread that periodically releases unused physical objects after a time-out.

How the Object Pool Manager works

As illustrated in Figure 5-17, when a Portlet makes a request to reserve an object, the Object Pool Manager processes the request through the following possible phases:

Matching a pooled object
Creating a pooled object
Replacing a pooled object
Queuing a request
Returning a FAILURE state

click to expand
Figure 5-17: Pool Manager process flow

Details about these phases follow the figure.

Matching a Pooled Object

A client makes a request of a virtual object. It communicates with the Object Pool Manager to bind the virtual object to a matching physical object. The virtual object then repeats the client's request, making this same request of the matched physical object.

If a match is found, the Object Pool Manager reserves the matching physical object and sends it back to the requesting client. If no matching object is found, then the Object Pool Manager proceeds to the next phase of processing logic-attempting to create a physical object.

Creating a Pooled Object

If no matching object is found, the Object Pool Manager checks its MaxPoolSize setting before trying to create a physical object. MaxPoolSize determines the maximum number of objects a pool can contain.

If the number of objects in the pool is less than MaxPoolSize, then the pool is allowed to grow. As a result, the Object Pool Manager calls the CreateObject() method. A successful call returns a physical object to the requesting client. An unsuccessful call indicates that a critical resource is unavailable. For example, if an application requests a session but the Domino server is down, then the call to CreateObject() would fail, and a FAILURE state would be returned immediately

Replacing a Pooled Object

If an object pool is at the limit set by MaxPoolSize, then the pool is considered full. As a result, instead of trying to create an object, the Object Pool Manager attempts to recycle an almost expired object and create a new one that matches the one requested.

Only unreserved objects can be replaced, so the Object Pool Manager first checks whether any objects are free. Assuming there are unreserved objects, the Object Pool Manager next calls the StealObject() method to determine which object to replace.

The Object Pool Manager calls the ReleaseObject() method to destroy the object to be replaced. As a result, the pool now contains one slot to fill, and the CreateObject() method is immediately called.

Queuing a Request

The fourth phase of processing occurs under the following conditions: if no matches are found, if the pool is full, and if none of the objects is free to be replaced. Under these conditions, the Object Pool Manager queues the request. The request waits until an object is returned to the pool. Pooled objects are returned to their originating pool when a client is done using them.

If the waiting period is within a maximum allowable idle time, then the request processing starts over from the beginning, with an attempt to match the newly returned object. The maximum allowable idle time is configurable through the MaxWait variable in the registry.

Returning a FAILURE State

If the request is queued for longer than the MaxWait time, then the request finally fails. Frequent request failures may indicate a need for the server administrator to review an object pool's configuration settings.

Maintenance features of the Pool Manager

In addition to processing object requests, the Pool Manager is also responsible for maintenance of the Object Pool. The Pool Manager prevents session time-outs and destroys physical objects in the pool, based on idle time or usage limits.

What the Pool Manager can do for you

In the context of Domino Portlet development you can use the Pool Manager to manage, for example, DIIOP sessions and associated view objects. The following scenarios illustrate the advantages of using the Pool Manager:

One user, multiple Portlets

In this case pooling session objects will help you to reduce the access time to a page since the session object is created only once and then shared by all Portlets.
User group, multiple Portlets

This shows the efficiency of the Pool Manager best. Besides sharing sessions for users of the same group, we can share view objects as well.

On Portal places you will find that this is a common scenario. Users having access to a Place usually have the same access rights to the underlying Domino applications as well.
One user one Portlet

In this case we do not have any advantage, aside from the fact that implementing the Object Pool once is going to reduce coding time for Domino Portlets in the future.

You can see that implementing a Pool Manager has a lot of advantages over handling Domino objects manually. It especially helps to avoid problems like session time-out and DIIOP memory leaks. It also ensures thread-safe access to view objects, and allows object sharing and the implementation of load-balancing to ensure high performing and scalable environments.

Taking the Pool Manager to the next level

So far we have used the Pool Manager only to manage physical Domino objects. Earlier in this chapter we introduced the Model-View-Controller design pattern. If you want to implement your Portlets in this manner, you should consider transforming the physical Domino objects into abstract objects. You then can use these abstract objects to render the output on the JSP pages.

Introduction to Queries

If you look at a Portlet you see that most of the time it displays information in a view-like manner. The data can be the result of displaying a view or a search result. In many cases you will also find navigation that enables the user to navigate through the data.

A representation for this can be seen as a Query object.

The query is a collection that is used on the JSP page to display the result of an executed Query Definition.

To create a Query Definition the Portlet specifies the server name, database, and view name. It can set page size and maximum result size. It also defines the columns to be included in the results.

The Query Definition is then submitted to the Pool Manager that executes it and sends back the resulting Query object. This is then passed to the JSP for rendering. The Pool Manager also returns a query ID. This can be used in subsequent calls to the same query to retrieve, for instance, following pages without having to execute the query again.

Caching query results is also possible and another way in increasing Portlet performance. In addition, you can envision the reuse of queries between users in the same user group.

Access to Domino documents

From the query object, the next logical step is to allow access to Domino documents. This can be implemented using the Pool Manager as well. If you have access to a Domino document it is also easily possible to implement write access.

Summary of object pooling

Abstracting Domino objects though the use of virtual objects is an elegant approach to implement the Model-View-Designer design pattern. It also helps in building better performing Domino Portlets.

You can find further information on creating object pools from the Jakarta "Commons Pool" project at

http://jakarta.apache.org/commons/pool/

This project provides an Object-pooling API, with three major features:

A generic object pool interface that clients and implementors can use to provide easily interchangeable pooling implementations.
A toolkit for creating modular object pools.
Several general purpose pool implementations.

We can think of many ways to extend the concept of query objects even further. Consider, for example, a Compound Query that was able to aggregate the results of multiple underlying query objects. This would allow you to build views across multiple Domino views and databases.

The discussion of this topic is out of the scope of this redbook. Third-party vendors like CONET have implemented very sophisticated data management concept in their products. For example, their Domino Warehouse Model allows for combining of data from multiple Domino databases, as well as append, merge, and mix of Domino data.

< Day Day Up >