Explanation of Maximo Application Server Connection Pooling and Management
The Maximo Application Server maintains its own pool of available database connections and assigns them to Maximo Business Objects upon request. This document explains the controlling parameters and how the connections are maintained.
Resolving the problem
Maximo Connection Manager
Maximo has its own Connection Manager which maintains a pool of available connections based on the parameters in the properties file. Using the default properties values for this example, Maximo obtains 15 initial connections (mxe.db.initialConnections) at start up. The Connection Manager then maintains a pool of established connections to issue to objects upon request. It tries to keep the connection count between 10 (mxe.db.minFreeConnections) and 30 (mxe.db.maxFreeConnections). If the pool drops below 10, it adds 5 new connections (mxe.db.newConnectionCount) at a time until the pool count exceeds 10. If it exceeds 30, it drops them one at a time until there are 30 available (idle) connections.
For Maximo 5 only, when a user first logs on, Maximo makes one brief database connection as user/pswd in order to validate that userid, then immediately disconnects after success or rejects the login attempt upon failure. Maximo 6 and later versions do not maintain the users as database users and do not make a database connection for user authentication.
From the database perspective these connections will show as active or inactive. An inactive connection can be any one of the following:
- A connection assigned to an object that is in between SQL executions.
- A connection that is in the available pool, waiting for assignment.
- A connection that has been assigned to an object, but the user has exited by pressing the X in the corner of IE instead of logging off.
In the third case, the user's threads will eventually be timed out (default 30 minutes) and then the garbage collector will clean up the object on the next pass and return the connection(s) to the available pool. The timeout value is set in the file web.xml which is in the WEB-INF directory.
Note that if there are any custom written Maximo objects or extensions that make their own connections to the database rather than utilizing the connection pool, they will not be cleaned up by the timeout/garbage collection process after an abrupt user exit. They will remain as inactive connections to the database until Oracle or SQL Server cleans them up, which might not occur until database shutdown.
Maximo's Connection Manager monitors the status of it's connection pool. If it discovers that the connections have all failed, typically due to database shutdown, it will continuously attempt to connect to the database until successful. Once one connection is successful, the Maximo Application Server will establish a number of connections equal to mxe.db.initialConnections and go through start up initialization.
This is not a transaction failover mechanism. Uncommitted transactions will be lost if the database is shutdown abruptly or a network failure occurs. It does mean that the database can be shutdown for scheduled cold backups without the need to shut and restart the Maximo Application Server.
Note that this capability to automatically reconnect only applies to a Maximo Application Server. It does not apply to WebMethods B2B (only used with the Maximo 5 MEA and eCommerce Adapter).
|Systems and Asset Management||Tivoli Asset Management for IT||All|
|Systems and Asset Management||Maximo Asset Management Essentials||All|
More support for:
Maximo Asset Management
Software version: 5.2, 6.0, 6.1, 6.2, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 7.1, 7.1.1, 7.5, 7.6
Operating system(s): Platform Independent
Reference #: 1262164
Modified date: 10 December 2008