Pooling Thin Graphs

When you use BI Beans thin graphs, you must consider how to support the number of users that you anticipate. You could create a new instance of a thin graph for each HttpSession, but this can result in a great number of instantiated graphs at a time if you have many users. Alternately, you could use a single instance of a thin graph for all users, but then you must set the state of the graph each time any user wants to see a graph.

Graph pooling allows you to maintain a set, or "pool", of graphs, which you can use in your servlet application. The pool allows you to maintain fewer graphs than one for each HttpSession, but enough so that users do not have to wait a long time, while graphs are being configured and rendered to fill requests from other users. Your application gets ThinGraph instances from the graph pool, configures the instance for the user, and releases the graph when the user no longer needs it.

When you use graph pooling, you do not store the ThinGraph in the HttpSession. Instead, you store the Query in the session, and you set the Query on the ThinGraph that you get from the GraphPool.

Getting and configuring graphs

As you initialize your servlet application, you create a GraphPool object. When you need a ThinGraph, you do the following in a try block:

  1. Get a ThinGraph by calling the getThinGraph method of the GraphPool.

  2. Configure the graph for the requesting user. This is basically setting the state of the graph. It generally involves setting the DataSource property to apply the Query to the ThinGraph, and setting any other properties for customizing the graph. You can apply XML to the graph to set all these properties at once. You can store the XML in the session, if you choose.

  3. Render the ThinGraph, by associating it dynamically with a GraphBean .

Releasing a thin graph

When your user no longer needs a ThinGraph, then call a GraphPool.release method to release the thin graph to the pool, for use with other users. You should put this call in a finally block to ensure that the thin graph is released, even if an exception is thrown.

Configuring the graph pool

The graph pool is dynamic, so you can configure the size of the pool to respond to the changing needs of your application. The GraphPool class extends the PoolDispatcher classes, where the configuration parameters are defined statically. The following parameters affect the size of the pool:

You can set these parameters in the constructor of the GraphPool, or you use a different constructor to accept all of the default values. To set some parameters but use the default value for others, you can pass the constants in the PoolDispatcher class for the default parameter values.

The best settings for these parameters depends on how many users you have and how much configuration you perform on a graph after you get it from the pool. In general, if you have more users or more intensive graph configuration, then you should maintain a larger pool.