Category: Technical

There are 2 very detailed posts on IBM DeveloperWorks written by Manjunath about database connection leaks – how to detect them and how to resolve them.

Maximo — How to detect database connection leak
Maximo — How to solve database connection leak

Here is the crux –

To free up locked database connect in maximo, IBM has introduce 3 new system properties (7.5.0.3 onwards) –

mxe.db.closelongrunconn – default is false.

mxe.db.longruntimelimit – default 180 minutes.

mxe.db.detectlongrunconninterval – default is 30 minutes. This is the frequency in which the long running connections are checked. Cannot be less then 30 minutes.

The mxe.db.closelongrunconn property when set to true will close the lost connections if the connections have been held for greater than mxe.db.longruntimelimit time and were not used by any processes in that time duration.

---

To detect database connection leak, turn Maximo dbconnection watchdog logger to INFO and collect the logs for 1-2 days. If there are any connection leaks the logs will show some thing like this –

[INFO] BMXAA7084I – The DbConnectionWatchDog class has been trying to close the database connection for: 230233001 ms

DbConnectionWatchDog:Db Connection reference id=436107 SPID=397
Create time:1302986384636
Life time:230233001 ms

The Logger indicates that the connection as being held for 230233001 ms i.e. approximately 64 hours. By looking in the logs at approximately 64 hours back, one should be able to find the stack trace of where this connection was established

Sometimes when I am in a hurry and I have to close my browser which has multiple Maximo sessions open, it is very frustrating to see each tab asking me to click on ‘Leave This Page’ to close it even after signing out from one of the tabs.

There is a property in Maximo – webclient.exitwarn to disable this. By default its set to 1. Setting it to 0 from the system property application will disable the confirmation box. This doesn’t require a restart to take effect as this property is Live Refresh enabled.

Sometimes when I am asked to look into some issue or I have to debug some out of the box functionality in Maximo, I start wondering where to start.

Logs are one good place to start debugging. Turning the logger level of appropriate loggers to debug prints lots of information in the system out (which can be a performance overhead also so be cautious).

To print more specific details of the class that is writing these logs there is a tweak that can be done in the logging application.

In the logging application, in the Manage Appenders dialog in the select action, select the console appender. In the table details, update the Conversion Pattern to

–CLASS -> %C LINE -> %L %d{dd MMM yyyy HH:mm:ss:SSS} [%-2p] [%s] [%q] %m%n

This will print the classname and the line number for all the log entries made in the systemOut.log and maximo.log, which will look something like this –

This can be the starting point for your debugging. If you created custom appenders, this tweak can be implemented on the custom appenders leaving the console appender as it is.

Did you know that you can create lookups in Maximo (in the lookups.xml) with whereclause and attach it to an attribute in application designer. The attribute doesn’t require a domain to be attached to it to show the data in the lookup .

The lookup will simply query the object mentioned in the mboname with the whereclause and display the result. The only drawback to this approach is that there is no validation on the attribute – any value entered in the field would be accepted without any validation.

The where clause also accepts run-time variables such as :user.

This is useful in places such as report request pages where a parameter needs to be passed to the report with a lookup which shows much filtered data then is usually shown in the lookup in the application.

For instance this asset availability report request page has a parameter as Tool which only shows items of type tool and not all the items.