Enterprise Java

User sessions, Data controls and AM pooling

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.

 
 
 
 
 
 
 
Screen Shot 2014-10-27 at 3.49.26 PM
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:

Screen Shot 2014-10-27 at 3.56.01 PM
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.

Screen Shot 2014-10-27 at 4.08.13 PM

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.

Screen Shot 2014-10-27 at 4.20.24 PM

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.

Screen Shot 2014-10-27 at 4.42.15 PM

That’s it!

Reference: User sessions, Data controls and AM pooling from our JCG partner Eugene Fedorenko at the ADF Practice blog.

Eugene Fedorenko

I am a Senior Architect at Flexagon focusing on ADF and many other things.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button