What happens with AM instance, when Web session times out? I would like to answer this question. To find an answer, I have developed sample application with special settings for AM configuration - AMInstanceTimeoutApp.zip. This is important to understand, because we should try to avoid frequent AM passivations, same as frequent AM activations. Passivations consumes server resources and delays request processing for current active users.
We already know - when AM idle instance timeout is set to be less than Web session timeout, during user inactivity there will be AM passivations and activations happening. To minimize number of passivations/activations, we need to increase Referenced Pool Size, along with increasing AM idle instance timeout (read here - How to Minimize Number of ADF BC Application Module Activations).
Customized AM settings for the sample application:
1. Referenced Pool Size = 1, to simulate high load and to see what happens when second user arrives
2. Minimum Available Size = 0, to make sure all AM instances will be removed after timeout
3. Idle Instance Timeout = 900 (sec.), instance will be marked as candidate for removal after 15 mins.
4. Pool Pooling Interval = 60 (sec.), inactive AM instances will be removed in 1 minute intervals
![]()
Web session timeout on contrary to AM instance timeout is set to be less - only 5 minutes. This is done on purpose to timeout Web session, before associated AM instance will be timed out:
![]()
As practical test shows - once Web session times out, if another user accessing application before pool pooling interval - passivation will happen. This means, AM instance was not yet removed and is still reserved - as there are no available AM instances (Referenced Pool Size = 1), passivation happens and instance is given to the new user.
Web session times out for the first user:
![]()
Second user is accessing application, passivation happens for the AM instance previously used by already timed out session:
![]()
However, if second user would wait a bit more after first user session timed out - precisely would wait until pool pooling interval, there would be no passivation. This means, when Web session times out - AM instance is not removed instantly, it will stay active until the next even of pool cleanup (pool pooling interval). In my sample I set this interval to 1 minute, in real application it could be 5-10 minutes.
Web session timeout happened and after pool pooling interval - AM instance was removed:
![]()
If second user is accessing application at that time, there will be no passivation reported:
![]()
We already know - when AM idle instance timeout is set to be less than Web session timeout, during user inactivity there will be AM passivations and activations happening. To minimize number of passivations/activations, we need to increase Referenced Pool Size, along with increasing AM idle instance timeout (read here - How to Minimize Number of ADF BC Application Module Activations).
Customized AM settings for the sample application:
1. Referenced Pool Size = 1, to simulate high load and to see what happens when second user arrives
2. Minimum Available Size = 0, to make sure all AM instances will be removed after timeout
3. Idle Instance Timeout = 900 (sec.), instance will be marked as candidate for removal after 15 mins.
4. Pool Pooling Interval = 60 (sec.), inactive AM instances will be removed in 1 minute intervals
Web session timeout on contrary to AM instance timeout is set to be less - only 5 minutes. This is done on purpose to timeout Web session, before associated AM instance will be timed out:
As practical test shows - once Web session times out, if another user accessing application before pool pooling interval - passivation will happen. This means, AM instance was not yet removed and is still reserved - as there are no available AM instances (Referenced Pool Size = 1), passivation happens and instance is given to the new user.
Web session times out for the first user:
Second user is accessing application, passivation happens for the AM instance previously used by already timed out session:
However, if second user would wait a bit more after first user session timed out - precisely would wait until pool pooling interval, there would be no passivation. This means, when Web session times out - AM instance is not removed instantly, it will stay active until the next even of pool cleanup (pool pooling interval). In my sample I set this interval to 1 minute, in real application it could be 5-10 minutes.
Web session timeout happened and after pool pooling interval - AM instance was removed:
If second user is accessing application at that time, there will be no passivation reported:
