MAXIMO : Performance Best Practices - MboSet

 This article details  java /script based customization best practices when getting MboSet and related Mbo's for business logic.

Broadly there are two way's to fetch MboSet in the code.  Either using relationships be it those defined in database configurations or through dynamic relationships being created within Code , or using MXServer class.

There are times when we need to use one of these approach to fetch required MboSet and its not like never use MXServer to fetch MboSet which is misconception many folks have as part of Maximo coding standards or guidelines.

Here I would be discussing more specifically on MboSet being fetched via MXserver  and required considerations while using this approach , lacking it would have serious concerns around memory cleanup/OOM or stuck thread issues or sometimes even undesirable or inconsistent results.

Below are are rules of guidelines to be considered while getting MboSet from MXServer reference.

1. setwhere() and reset()

Almost all the time you should have dedicated where-clause to be applied when MboSet is fetched via MXserver  as without that it will load all the records from  set into memory ( as per fetch limit)  will be both performance heavy and in-effective memory usage . Hence setwhere() should be used to filter for appropriate criteria to load required data only. Then reset() is actually doing getting data from database as per applied clause in setwhere() into the memory.

MboSetRemote assetSet = MXServer.getMXServer().getMboSet("ASSET", getUserInfo());
assetSet.setWhere("LOCATION='BEDFORD'and status='OPERATING'");
assetSet.reset();

2. In case this set is being fetched to add new records and not for traversing current records

the ideally sethwere should be something like below to get empty set

assetSet.setWhere("1=2");
assetSet.reset();

3. If set is to be used only for traversing the record without any add/update/deletion then it should have DISCARDABLE flag set to true so it wont consume memory and dont get included in cached in memory and will be always readonly.

assetSet.setFlag(DISCARDABLE, true);

4. Additionally if set being fetched is not to be saved  then NOSAVE flag can be set to its not get included in respective transaction.

 assetSet.setFlag(NOSAVE, true); 

5. Incase set is fetched from MXServe it wont get automatically included in MXTransaction and hence save() should be explicitly called for any data add/change operations on set else it will be lost. This is not required when MboSet is fetched via relationships or through coding dynamic relationships.

Always call clear() and close() on the MboSet fetched from MXServer once it is certain that it is not required anymore. This releases the memory and the database resources. If the set is not closed, it will remain in memory till it is collected by the garbage collector which could be a long time

assetSet.clear();
assetSet.close();