Recently I was asked an interesting question about application module pooling. As we know AM pool contains application module instances referenced by user sessions, which allows a session to fetch exactly the same AM instance from the pool at the subsequent request.
And if there is more than one root application module in the application, then each of them is going to have its own AM pool:
And how about the situation when the application handles more than one instance of the same root application module. For example any kind of UI Shell application where each tab runs a task flow with isolated data control scope.
In this case a user session references several AM instances in the pool. For this particular example there are going to be four AMs in the pool referenced by one session. One for the menu and three for the tabs.
So the question is how come the framework doesn't mess it all up and knows exactly which AM instance in the pool should be used by each tab. The answer is that an application module instance in the pool is not directly referenced by a user session. Instead of that it is referenced by a SessionCookie object which is unique for each DataControl instance. Since the task flows in the application have been run with isolated data control scope, there is a separate DataControl instance for each of them.
That's it!
And if there is more than one root application module in the application, then each of them is going to have its own AM pool:
And how about the situation when the application handles more than one instance of the same root application module. For example any kind of UI Shell application where each tab runs a task flow with isolated data control scope.
In this case a user session references several AM instances in the pool. For this particular example there are going to be four AMs in the pool referenced by one session. One for the menu and three for the tabs.
So the question is how come the framework doesn't mess it all up and knows exactly which AM instance in the pool should be used by each tab. The answer is that an application module instance in the pool is not directly referenced by a user session. Instead of that it is referenced by a SessionCookie object which is unique for each DataControl instance. Since the task flows in the application have been run with isolated data control scope, there is a separate DataControl instance for each of them.
That's it!
This is a great post.And I am asking you to extend it. The post itself is very nice and the graph help a lot to illustrate the concepts. Just when I got really engaged to keep reading it finished.
ReplyDeleteWould be great if you further the post by talking about how the AM Poll works - I was expecting to see something about pasivation/activation or how to configure correctly the AM Parameters (rather than leave the out of the box values).
Nevertheless, its a great post!
Thanks for the warm feedback.
DeleteThere is a great set of videos by Chris Muir covering all aspects of AM pooling in details. I think this job can't be done better.