Nested application module is batter then root application module.
In case of Nested application module in one connection you can use all the nested application modules
but in case of root application module, for each application module it will create one one connection.
for more info you can click the below link
From a practical point of view if you have some VOs that have to appear in more than one AM (let's say in AM "A" and "AM "B"), you can define a separate AM "C" and include these VOs in it, then include the AM "C" as a nested AM in both AM "A" and AM "B" definitions. If you add/remove some VOs to AM "C" later, this change will indirectly affect the AM "A" and "B" too. This is very useful if you have a large data model and you have groups of VOs and service methods (e.g. "modules") that have to be included in multiple AMs.
You may have a look at the documentation:
You can think of a nested AM as a logical group of some VOs and service methods within the root AM.
You cannot explicitly instantiate an AM as a nested AM at runtime. You always instantiate a root AM and it automatically will instantiate the necessary nested AM instances internally.
The root AM keeps the DB connection and the transaction object. The nested AMs do not have their own connections and transaction objects, the nested AMs use the connection and the transaction object of the root AM (i.e. a root AM and its nested AMs share the same connection and transaction object). This means that you cannot commit/rollback a particular nested AM instance independently from the root AM and from the other nested AMs of this root. The root AM and its nested AM instances are committed/rolled back at once.
Google has a nice search engine that produces results for your question when you enter: ADF BC Root AM nested AM into the search field (the only field on the page when you issue www.google.com . One of the links it brings up is
And many more. Let me know if you have a problem using Google and I am happy to help