My last article discussed the DB Connection Watchdog component and its role in detecting DB Connection leaks.

The DB Connection watchdog was updated in 7.6 so when a JVM is shutdown it writes a full report of the DB connections that it is concerned about. This is still not ideal and the best solution would be if the system administrator could modify the interval at which the reports are generated. Currently the report is generated every 30 minutes.

Tip -> If you suspect a leak then gather the logs after the JVM has been shutdown and look for warning log entries. You should always check the report after test runs.

This new functionality is particularly important for testing because prior to 7.6 the reports would only be generated after the JVM had been running for 30 minutes.

The DB connection watchdog does not report on the connections used by the Cognos and BIRT reports. They manage the DB connections using different technologies that are not monitored by the DB Connection Watchdog.

Making Maximo better in the longer term – RFE 50987

This RFE proposes changing the DB Connection Watchdog so that it provides its key information more frequently or even on demand. This would help system administrators identify and resolve these types of leaks.

The RFE is currently at status “Declined” with 19 votes. However if you feel that this would help your organisation then please vote for it (and add it to your watchlist) as it may be possible that IBM will reconsider this request.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=50987

BIRT reports and DB Connection leaks

BIRT reports use datasets to query the database and the datasets need to be closed. Maximo / BIRT will automatically close some datasets but if additional “sub” datasets are created e.g. in a fetch method, then they should be explicitly closed. If they are not explicitly closed then the associated cursor can then leak. The reporting team updated the 7.6 Report Development guide to include information about how to prevent leaks when writing reports. The new information doesn’t cover all the possible cases but the information is clear enough that it should be possible to identify leaks.

Report developers for earlier versions who want to understand about leaks should read the guide as the example there can be applied to previous BIRT versions.

Vetasi customisation – Search BIRT reports and automation scripts for possible connection leaks

Vetasi use automated tools to search for leaks in BIRT reports and automation scripts, these tools generate easy to read reports that identify the suspect code and allow developers to quickly jump to the heart of the problem.

The analysis from the BIRT reports tool has led to a significant number of reports being fixed in both 7.5 (IV81529) and 7.6 (during the beta testing).

Vetasi offers consultancy to check BIRT reports and automation scripts for possible database connection leaks. This consultancy uses the same automated tools referred to above so the analysis can normally be generated very quickly.

If you suspect that you have DB connection leaks then contact Vetasi and we can help resolve any issues you have.

Reduced dependence on the database from 7.6 onwards

The reliance on the database is being reduced from 7.6. This version introduced a new technology which means that more data is stored locally on the user’s browser as discussed in this blog posting about the Recent Applications list. The developers are looking at using more of these caches in the future as a way to speed up the front-end.

These caches will present a challenge for support staff as we may receive calls if the caches become out of sync with the database or become too large.

If you like this article then please share or like it. Why not look at the other articles listed in this index.