When using MXServer for fetching MboSet

There are two ways of fetching a MboSet in java code, either using a relationship or through MXserver. There are different benefits for using either of these and different scenarios may need one of these ways to be used. For now, we are going to talk about MboSet fetched from MXServer.

When fetching a MboSet from MXServer, there are a few things that one needs to be careful about. Poor knowledge of these may result in performance issues, poor memory management and undesirable outcomes.

There are six simple rules to keep in mind when fetching MboSet from MXserver. These rules are as follows –

  1. Always use setWhere() and reset() on the set fetched from MXServer. The where clause that you give in the setWhere will reduce the no. of MBOs fetched in the set. The reset will get the data from the database using the where clause. If the setWhere is not used, the entire set is fetched from the database which means the entire table is fetched into the memory.
MboSetRemote assetSet = MXServer.getMXServer().getMboSet("ASSET", getUserInfo());
assetSet.setWhere("LOCATION = 'BEDFORD'");
  1. If the set is being fetched just to add new MBOs and not for traversing then use 1=0 as where clause in the setWhere. This will fetch an empty set.
  1. If the set is being fetched just for traversing and not for any addition or updates set DISCARDABLE flag as true on the MboSet. Discardable MboSets are not cached in memory, they can only be traversed in forward direction and cannot be saved.
assetSet.setFlag(DISCARDABLE, true);
  1. If MboSet is fetched for readonly purpose, set NOSAVE flag as true. This way the MboSet won’t be added to the MXTransaction which would shortens the looping time of the transaction.
assetSet.setFlag(NOSAVE, true);
  1. If an add or update transaction is being performed on an MboSet, do not forget to call save(). Contrary to popular belief that save shouldn’t be called explicitly in java code, MboSet fetched from MXServer must be saved before the set is closed otherwise the changes would be lost. MboSets fetched from relationship do not require a save to be called explicitly because their save is called when their parent is saved. Hence the belief.
  1. 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.

clear and close shouldn’t be called on an MBOSet fetched from a relationship. This will give undesirable results.

So keep in mind these simple rules next time when you are fetching a set from MXServer.

In my next post I will try to explain you the difference between clear(), cleanup() & close(). Stay tuned.. 🙂

isNew() vs toBeAdded() Methods in MBO

Often this question is asked that what is the difference between isNew() and toBeAdded() methods of the Mbo. Before I explain the difference let me tell you what these methods are –

  • isNew() – Returns whether the mbo is new or not. true, if the mbo is new (i.e. created by calling add() or insert() methods), otherwise false.
  • toBeAdded() – Returns whether the Mbo is to be added to storage
  • toBeDeleted() – Returns whether the Mbo is to be deleted from storage
  • toBeSaved() – Returns whether the object need to be saved to persistent storage. This will also check child objects.

All these method are in the psdi.mbo.Mbo class and have a return type as Boolean.

The difference is explained using the scenarios in the below table

Scenario isNew()  toBeAdded() toBeDeleted() toBeSaved()
New Mbo Added True True False True
New Mbo Added, deleted before saving the Mbo True False True False
Existing Mbo updated False False False True
Existing Mbo deleted False False True False

All about Count Method

Although it is discouraged to use the count method of mboSet as it hits the database to get the count but at times it can be very useful. There is an overloaded method count(int countConstant) that can be used to get the count of mbos that are in different state in the mboset.

Here is the explanation of the parameter –

countConstant – one of the constants from psdi.mbo.MboConstants. The list below shows each constant and describes the count returned for each.

  • COUNT_DATABASE — The count from the database.
  • COUNT_ADDITIONS — The count of newly added Mbos that have not yet been saved.
  • COUNT_DELETED — The count of Mbos marked for deletion that have not yet been saved.
  • COUNT_EXISTING — The sum of the count from the database (COUNT_DATABASE) plus newly added Mbos that have not yet been saved (COUNT_ADDITIONS).
  • COUNT_AFTERSAVE — The number of Mbos that is anticipated to be in this MboSet after saving. Equals the sum of the count from the database (COUNT_DATABASE) plus newly added Mbos that have not yet been saved (COUNT_ADDITIONS) minus Mbos marked for deletion that have not yet been saved (COUNT_DELETED).

The count() method without the parameter is Same as count(COUNT_EXISTING).