Best Practice: Shared Application Module Usage

Shared Application Module concept comes handy when you have static data sets to be displayed in UI. In this case, instead of hitting database everytime a query is fired , it’s much better to use shared application module. Basically, the shared application module keeps the VO data cached and subsequent search queries hits the cache instead of db. Barring the first time (when the app goes up – shared AM takes a little bit of time initialize its VO caches, after that every subsequent queries would be much much faster).

But nonetheless, there are some to dos and not to dos around its usage. Here are some -

1.You should set the maxampoolsize to 1 as you want only one instance of shared AM to be used across user sessions. If not, then separate instances would be initialized and the prime purpose would be defeated. So, set this value judiciously.

2.The “iseExclusiveuse” flag of AM should also be set cautiously. If set it to false, then only one AM instance would be shared across all the sessions and if you inadventently do a setCurrentRow() on any shared AM VO then it may lead to inconsistent data to be displayed across multiple user sessions because the same VO cache would be used by all the users.

3.The “resetnontransactionalstate” flag should also be used cautiously. If you set it to false then bind variable
values that were set by the last client would also be retained.If it is not intentional then it may lead to incorrect result rows.