Question of the Week (QOW #1) : How long a shared Application Module will stay in memory?

I'm starting a new thread here. This category is primarily for sharing some interesting questions that I'm seeing while working with ADF developers. Questions will be posted in my blog on every Sunday. You can post your answers as Comments for the corresponding post. At the end of  each week I'll update the post with right answer.

Question of this week (QOW #1):

How long a Shared Application Module (shared at application level) will stay in memory (in other words, when would a shared AM be eligible for garbage collection)?   Post your answers as comments for this post.

Answer(Updated on 14 July 2014):

Thanks all for your answers and interests. I didn't find anything wrong in any answers, great job folks. Let me give you more detailed answer with right set of AM config property names that you may need to be aware of.

Before getting in to the answer, let me answer one related question, What exactly is the concept behind application level shared AM ?

An application scoped shared application module is shared across sessions. This is typically used for reading read only master data (used in LOVs or in similar use cases). A view object in an application scoped shared application module uses multiple iterators on top of a single row set for serving multiple clients. If the query used in the view object is parameterized, then multiple row sets are generated based on the bind parameter values supplied by the client. These row sets are cached by individual query collection objects with unique bind variable combinations.

Now, answer for the question-

As normal(non shared) application module, jbo.ampool.timetolive configuration parameter can decide the life span of a shared AM instance as well. In other words, shared AMs are periodically released to the pool and the jbo.ampool.timetolive  is checked upon release. The default value for this property is 1 hour. However, the shared AM can only be removed if there are no other pool sessions referencing the AM upon release. In such cases AM will be released and JVM will remove it from memory during next GC(Garbage Collection) cycle

On a related note(to complete this discussion), connection pooling (jbo.doconnectionpooling=true) is not supported for use with shared application modules. Using same connection object across requests for a shared AM gives better performance when you have partially fetched result set. Also you must set  some string literal value for jbo.shared.txn of an AM shared at application level. This setting makes sure that all instances of the shared AM share same transaction context(which includes same JDBC connection and entity cache). This works well for shared AM as they are read only and not used for any data update (you are not supposed to use it in the other way).

Comments

Alok said…
I think If the scope of shared AM is selected as session than till the time session will be active, GC will be not invoked. If scope is Application than it will be active till the apps will be active.
Anonymous said…
Hi,

Good initiative Jobinesh, and thanks for your very usefull blog!

For the QOW, maybe it will stay in memory during the time configured in jbo.ampool.timetolive property?

h0s
KUCHI BHARGAV said…
even if the scope is session or application after the configured timeout interval it will be released to pool.(if there are no further requests to these modules).
the most interesting point i observed is application modules with session or application scope if we are dragging and dropping one of the iterators from data control panel to ui page resulting in creation of new application module instance it is not reusing the existing instance.
Thank you all for your responses. I updated the post with answer.
Anonymous said…
Is there a way to test this.. check the counts of App Modules.. being used/released...

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of my employer.