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).