分类：
2009-01-12 16:03:59
At a minimum, you need to supply a JNDI name for a data source that corresponds to a database to be used, as well as the database user ID and password to be used for accessing the database. Note that when specifying the data source, it should be a non-XA data source. This is because the session manager runs with the JDBC "autocommit on" parameter, and some XA data sources don't support the use of "autocommit on." Additionally, the update of the session database is not transactional, nor will the session database participate in transactions with other resources, so there is no need for using an XA data source with the session manager.
The default maximum pool size of 10 is a good starting point when sizing the connection pool for database persistence. Unless the session object is quite large or your site is handling thousands of concurrent users, it's unlikely that the pool will need to be much larger. In most cases, the default maximum will suffice, or perhaps a moderate increase (to 22–30) may be required. Recall that a connection pool is created for each application server instance, so three or four application servers result in three to four times that many total connection objects that are accessing the database.
Depending on the size of the session object, you may find it beneficial to use one of the other options available on this dialog. We'll discuss determining the size of the session object later in this chapter, but for large session objects, meaning those greater than 4KB in size, the options available can be used to improve performance.
When DB2 is used as the database, the page size can be adjusted from the default of 4KB to 8KB, 16KB, and 32KB. This allows the varchar database column used for the session object to fit onto a single database page. The result is faster performance for session objects that are approximately 7KB, 15KB, and 31KB in size.
The multi-row schema option can be employed to improve performance in some cases for large session objects, regardless of the database in use. With multi-row sessions, each attribute in the session object is stored in its own row in the database, instead of the default of storing all attributes in one column in a single row. This can be used to improve performance in two ways. The first is for non-DB2 databases, where WAS makes no provision to adjust the table page size. If each attribute stored in session is smaller than the page or block size for the database, specifying multi-row allows each row to be contained in a single database block. This can be combined with the optional write setting "only updated attributes" so that only the rows corresponding to each updated attribute are written to, instead of a write to all rows.
The other advantage to using multi-row sessions is that they allow you to have a session object larger than 2MB in size. Such extremely large session objects are most definitely not recommended from a performance and failover perspective, but WAS does provide a mechanism for dealing with objects of this size.
