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
.
As you initialize your servlet application, you create a GraphPool
object. When you need a ThinGraph
, you do the following in a try block:
Get a ThinGraph
by calling the getThinGraph
method of the GraphPool
.
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.
Render the ThinGraph
, by associating it dynamically with a GraphBean
.
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.
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:
Initial size -- The number of graphs to allocate when the pool is instantiated
Normal size -- The number of graphs to keep in the pool when none are requested
Maximum size -- The maximum number of graphs in the pool
Instance increment -- The number of graphs by which to increase the size when the pool grows.
Queue ratio -- The default ratio of the outstanding requests to available graphs; specifies when to increase 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.