Why checking for a record could lead to a memory leak

?

Task the developer was trying to achieve:

Check if there are any records associated with the current MBO.

The code (checkIfRecordPresent) should return true / false depending on if there are any records that match a set of criteria

Developers will often use this type of function to perform a check especially if different pieces of code need to perform the check.

The function will query the database and return a true/false value depending on whether the query returns a record.

The following diagrams show how this works in practice and why this can generate a leak.

?

If there is only one record in the MBOSet then the Maximo Framework will automatically close the MBOSet once that record has been read. This automatic closure prevents the MBOSet being leaked.

If there are multiple records in the MBOSet then the MBOSet can't be closed because the framework doesn't know if the code will want to access additional records.

?

The best solution is to use code that automatically closes the mboset immediately before the checkIfRecordPresent method returns its result.

try:

???????????????woSetObj = mbo.getMboSet("WORKORDER", userInfo)

???????????????// set the where clause for the MBOSet

???????????????woObj = woSetObj.getMbo(0)

???????????????// set flag to indicate if there was a record


finally:

???????????????if woSetObj:

???????????????????????????????woSetObj.close()

???????????????????????????????woSetObj.cleanup()

???????????????????????????????woSetObj = None

// return the flag so the calling method knows if there was an MBO in the MBOSet        

This is an example of the code that needs to be executed in the checkIfRecordPresent method.

This version of the code will close the MBOSet if it has been left open.

Calling the cleanup method makes it clear to the framework that the MBOSet is no longer required and the memory associated with the MBOSet can be freed.?

"Is this leak really a serious problem - it only leaks a few records in my case?"

This question was asked when I explained to someone why their code was causing a problem. A common reaction is to consider living with the problem ... after all it is just a few records....

The problem is that when you look at this from a system perspective it can become a very big problem.

Imagine the scenario where this is being triggered whenever an ASSET mbo is being loaded into memory. The code could be used to check if additional custom records have been added that are related to the ASSET.

If this the check was performed when a single asset MBO was being loaded then the impact would be low. However it is important to consider the wider picture.... Lots of ASSET mbos are loaded into memory when a user goes to the ASSET application and applies a query in the list view - that query will lead to ASSET MBOs being loaded into memory and each one of those MBOs could trigger this check. If a substantial number of those ASSET records had lots of associated records then a single user could trigger multiple MBOSets to be leaked.

This is one of the reasons that I always recommend testers check a standard set of operations as well as the functionality that the release is due to implement.

Should the developer be using the count(*) method in this situation?

?No – I will discuss why in a later article.

Should the developer be using the isEmpty() method in this situation?

I will discuss the problem with the isEmpty() method in a later article.

Should the developer be using a discardable MBOSet in this situation?

A discardable MBOSet is certainly an option if a new method is being written.

If an existing method is being patched then it is safer to use the finally block.

I will discuss discardable MBOSets in a later article.

Vetasi Advice

Follow the advice in this article – https://www.dhirubhai.net/pulse/general-mboset-closure-rules-mark-robbins/

?Use the try / finally / close technique to ensure that the mbosets are always closed

If you suspect there is a leak in your automation scripts then reach out to Vetasi – we offer a service that can quickly scan automation scripts for serious leaks including mbosets that are not being closed properly

Our automated tools can quickly check Maximo logs for evidence of resource leaks. Our processes mean that we can raise a fully described PMR within 10 minutes of a leak being found.

This blog series

This article is one of a series of articles to help system administrators understand the Maximo logs and the underlying architecture.

If you like this article then please share or like it.

Whilst I support the wider Maximo community and encourage the spread of knowledge, when republishing content from this blog please include the originating author along with the article or parts of.

If people do find parts of this blog coming up in blogs/newsletters/communications then please contact me directly. I’m happy to connect on LinkedIn to discuss.

Disclaimer

The postings on this blog are my own and don't necessarily represent Vetasi's positions, strategies or opinions.

The materials on this site are provided "AS IS" and the author will not be liable for any direct, indirect or incidental damages arising out or relating to any use or distribution of them. Readers are advised to test any changes/recommendations thoroughly before use

?