Java pooling enables you to create a “pool” of connections to xfServerPlus that are active and ready to use when a client sends a request. You can specify the minimum and maximum pool size, time-out values, and whether connections in the pool should be reused.
Depending on the requirements of your application, pooling can significantly improve performance by reducing the time necessary to establish connections and perform initialization processing. When connections are pooled, they are ready to go whenever the application makes a request, improving application responsiveness, especially on the client side. Pooling is of most benefit in JSP applications and in other Java applications, such as J2EE™ applications, where a single Java Virtual Machine instance is used.
How pooling works
When the pool starts up, it reads values from a pooling properties file to determine the configuration of the pool. The pool is populated with the minimum number of connections specified in the pooling properties file. (We recommend a minimum of at least three connections.) If you have written an initialization method (recommended), it is run when the connections are added to the pool.
When a client requests a connection, the request is satisfied from the connections available in the pool. Any Java class wrapper object that calls the usePool() method can use a connection from the pool. If no connection is available, a new one is created, up to the maximum size of the pool. Once the maximum is reached, requests can be queued for a specified length of time. The connections in the pool do not time out.
Reusing or discarding connections
When the client releases a connection, you can specify that it be either returned to the pool or discarded. By default, all connections are discarded after use; however, we recommend connections be returned to the pool for reuse if possible because it will improve performance, especially on the server side of your application.
To specify that connections be returned to the pool for reuse, set the returnPool option in the pooling properties file. However, if an untrapped exception is thrown on the connection, it is discarded, regardless of how this option is set. (Errors that your application traps do not automatically cause the connection to be discarded; the disposition of the connection depends on how your application handles it.)
In general, stateless connections may be returned to the pool, while connections with state (that is, those that persist data) should be discarded after use. The Synergy process that is attached to the connection may have state depending on whether the object that used the connection has state. Discarding a connection releases resources and ensures that the next client request receives a “clean” connection. If you decide to reuse connections, you can perform cleanup processing with the pooling support methods.
Error logging
Using an option in the pooling properties file, you can specify that any errors that occur during pooling be written to a log file. You can specify that informational messages be logged as well. See Specifying pool logging options for more information.
