AM使用指南之七：Configuration参数说明（2）

Application Module Pool 是用来存放有同一类型的AM 实例的池子，多个浏览器客户端可以“共享使用”少量的Application Module实例，这样就可以提高应用的性能。
只有根一级的Application Module才可以建立Pool，换句话说，内嵌的Application Module也将“共享使用”根一级的Application Module Pool，包括数据库连接，事务，缓存。
Application Module实例分为状态和无状态两种。
对于有状态的AM实例，它保存用户session的相关信息，用户做下一步操作时，将会继续使用该AM实例。
如果用户请求很多，AM实例已经接近峰值，那么将会“钝化”这些有状态的AM实例：即把有状态信息持久化。
然后把这些AM实例腾出来供其它用户使用，等到该用户继续做下一个有状态操作时，再用一个新的AM实例，并匹配“激活”刚才“钝化”的信息。

AM Pool主要参数说明如下：
1. Pool Behavior Parameters  
（1）Failover Transaction State Upon Managed Release：对应jbo.dofailover属性，默认false，建议设置为true。
带有未决事务的AM实例被释放回池中时是否执行“钝化”，即处于受管状态，以保证激活时可以继续事务。
（2）Disconnect Application Module Upon Release：对应jbo.doconnectionpooling属性，默认false，建议设置为false。
当AM实例每次释放回池中时，是否释放掉其对应的JDBC连接。不释放的好处是不用再从数据库连接池获取连接，并且prepared statements也可以直接拿来就用。
（3）Support Dynamic JDBC Credentials：默认true，建议设置为true。
允许开发人员程序在用户的Session开始的时候通过代码来修改数据库的连接的用户和口令。
（4）Reset Non-Transactional State Upon Unmanaged Release：默认true，建议设置为true。
当AM实例以无状态的方式释放回池中时，是否重置所有的Non-Transactional State，比如VO的运行时设置，JDBC 的Prepared Statements，绑定变量等等，保证放回池中的AM实例是“干净”的。
（5）Enable Application Module pooling：对应jbo.ampool.doampooling属性，默认true，建议设置为true。
是否使用AM池。建议生产环境设置为true，测试环境中为了明确与AM有关的问题时可以设置为false。
（6）Row-Level Locking Behavior Upon Release：默认false，建议设置为true。
强制AM 实例被释放回池时不去在数据库中创建一个pending transaction state。
ADF web application 应该设置锁定模式为乐观锁“optimistic”（默认为悲观锁“pessimistic”），以避免创建行级锁。

2. AM实例池大小参数介绍（Pool Sizing Parameters）  
（1）Initial Pool Size：默认值0，建议设置为AM实例最佳并发数+10%，即AM实例最佳并发数乘上（1+10%）。
初始化AM实例池时创建的AM实例的个数，在初始化AM实例池一开始创建一定数量的AM实例，这样不必在用户请求时再临时创建。
（2）Maximum Pool Size：默认值5000，建议设置为AM实例最大并发数+10%，即AM实例最大并发数乘上（1+10%）。
AM实例池中最多允许的AM实例的个数，也是最多允许的数据库连接数。如果请求的AM实例数超过该值，用户将会收到类似“没有可获得的AM实例或数据库连接”错误。
（3）Referenced Pool Size：默认值10，建议设置为有状态的并发的用户数。
AM实例池中最多允许的有状态（preserve session affinity）的AM实例的个数。
预估一下这样的并发用户有多少：做完某个操作后，短暂思考一下，继续下一个操作。
其好处是：一个有状态的AM实例将一直为一个用户服务，省去了钝化再激活的过程，节省了切换AM的时间。

3. Pool Cleanup Parameters  
（1）Minimum Available Size：默认值5。
AM实例池中最小可用的AM实例个数，即空闲的AM实例。
当AM实例不活动时间超过Idle Instance Timeout时，清理首先到达Maximum Available Size，然后如果还有满足条件的，继续清理，直到Minimum Available Size。
（2）Maximum Available Size：默认值25，建议设置为AM实例最佳并发数+10%，即AM实例最佳并发数乘上（1+10%）。
正常情况下，AM池中最大可用的AM实例个数，即处于工作待命的AM实例数。
当AM实例不活动时间超过Idle Instance Timeout时，清理首先到达Maximum Available Size，然后如果还有满足条件的，继续清理，直到Minimum Available Size。
（3）Idle Instance Timeout：默认值600000（10分钟），建议大于Session Timeout的时间，防止频繁做Passivation和Activation。
AM实例不活动时间，单位毫秒。当AM实例不活动时间超过此值后，将被标记为“可以清除”，并在下次AM池“大扫除”时被清除。
值得注意的是，即使AM实例被清除了，它依然关联着一个数据库连接，直到经过了AM的最大生存时间：Maximum Instance Time to Live。
（4）Pool Polling Interval：默认值600000（10分钟），建议设置为30000（30秒）。
AM实例池进行“大扫除”的时间间隔，单位毫秒。
（5）Maximum Instance Time to Live：对应属性jbo.ampool.timetolive，默认值3600000（1小时），建议大于Session Timeout的时间，防止频繁做Passivation和Activation。
AM 实例池中每个实例允许存活的最大毫秒值，当AM实例超过该值以后，将被标记“可以清除”，并在下次AM池“大扫除”时被清除。
默认值为1小时，实际上是不太合适的，因为在此期间用户的访问量可能很多，导致AM的实例数也很高，而每个AM又关联着一个数据库连接，最终数据库连接耗尽。

重要说明：
（1）所有的参数均是针对在一个JVM上运行的Application Server（如WebLogic Server）上的设置，如果是在集群的情况下，要除以Application Server的个数。
因为AM Pool是建立在每一个Application Server上的。
（2）WebLogic Server上数据库连接池有一个参数：Inactive Connection Timeout，应该设置为0。这样做是为了不与参数Disconnect Application Module Upon Release冲突。
即完全由AM来决定是否把数据库连接释放回数据库连接池。
（3）参数Idle Instance Timeout、Pool Polling Interval、Maximum Instance Time to Live 是相关联的。
Maximum Instance Time to Live（2分钟） 大于 Idle Instance Timeout（1分钟） + Pool Polling Interval（30秒）：每经过30秒，AM池清除那些不活动时间超过1分钟的AM实例；每个AM实例2分钟后，释放其关联的数据库连接。

参考文献：
1. http://www.oracle.com/technology/products/jdev/howtos/10g/adfbc_perf_and_tuning.html
2. http://www.oracle.com/technology/products/jdev/tips/muench/ampooling/index.html
3. http://www.avromroyfaderman.com/2008/10/adf-bc-tuning-i-entity-objects/
4. http://huraky.javaeye.com/blog/577791

5. http://andrejusb.blogspot.com/2010/02/optimizing-oracle-adf-application-pool.html

http://maping930883.blogspot.com/2012/07/adf158amconfiguration2.html