5.3.2 Stateless connections
The majority of call.connect beans and all vendor.connect beans are common stateless session beans and use stateless connections. One method call (typically one interaction between the client and the server) obtains a stateless connection from the WebSphere datasource, performs the necessary work, and then returns the connection to the pool.
If all clients would execute a method at exactly the same time, then you would need one connection per client. A single call.connect client sometimes obtains two independent connections for reasons of transaction boundaries.
In an extreme case, the number of stateless connections required could be twice the number of clients. However in practice, this is extremely unlikely. You should attempt to estimate the likely number of simultaneous connections. Once the system is running, you can verify your estimate with the WebSphere Resource Analyzer. If your value is too low, then clients will have to wait for connections and response times may become unpredictable. If the value is too high, then you will use more iSeries resources than required. If you are in doubt, err on the high side, a small number of active but idle connections is unlikely to be a problem.
If call.connect and vendor.connect are on the same iSeries, then you can configure them to use separate datasources or a common one. The pros and cons of the choice are complex. A common source may reduce the number of connections required since it is unlikely that both applications will reach their maximum usage levels at the same time. On the other hand, sharing the connections means that all connections accumulate prepared statements from each application. Therefore, they have a larger memory requirement per connection than if they were separated. A simple setup uses a common pool. Unless you have a reason to do otherwise, you should retain this.
The size of the datasource connection pool can be controlled using the WebSphere console. Start the console and select the datasource used by your application. On the WebSphere Console’s DataSource panel (Figure
The maximum pool size has the most significant affect on performance. If it is insufficient, then clients are forced to wait when they need a connection. In extreme cases, the application can lock up. The ideal tuning technique is to use the WebSphere Resource Analyzer to monitor actual use. A simpler approach is to make a high estimate and drop it down gradually until it impacts performance. Except for extreme values, performance is not greatly affected by this setting.
The minimum pool size is less significant but worth considering. This is the number of connections that WebSphere will retain even if they are not in use. The default of 1 is reasonable if there are extended periods in which WebSphere is not in use but other applications are. However, if there will rarely be times when WebSphere is idle, or when WebSphere and most other applications are idle, then a larger value is desirable. Larger values should improve startup times after periods of inactivity. Try to estimate the lowest level of WebSphere usage while other applications are busy. Ignore periods when WebSphere and other applications are not busy.
Chapter 5. Performance tuning 123
