Passivation/activation in ADF BC is designed to keep temporary user data across requests, when there are more online users than application pool can handle. If you are new to this, please read from Oracle developer guide - 40 Application State Management. There is added cost to passivation/activation - additional SQL execution. During activation event, its not only temporary data gets initialized - but complete VO SQL gets executed again. This means system could suffer significant performance issues, if there are lots of passivation/activation events happening. In order to avoid frequent passivation/activation, make sure to tune referenced pool size properly for your environment - Stress Testing Oracle ADF BC Applications - Passivation and Activation.
This post demonstrates additional SQL execution during activation event. Download sample application - ActivationSQLApp_v2.zip.
Form is loaded for the first time:
One SQL execution happens as it should:
We are running test with AM pooling disabled, this allows to simulate stress test environment and trigger activation/passivation events:
With AM pool disabled, without closing screen, press Next button in the form - this will navigate to the next record:
SQL will execute one more time:
From the detail log, we can see that SQL execution event is logged as well, when there is activation event:
During normal scenarios, SQL is executed once and data stays in memory. Keep attention, how often passivation/activation happens in your system - this can affect performance significantly.
This post demonstrates additional SQL execution during activation event. Download sample application - ActivationSQLApp_v2.zip.
Form is loaded for the first time:
One SQL execution happens as it should:
We are running test with AM pooling disabled, this allows to simulate stress test environment and trigger activation/passivation events:
With AM pool disabled, without closing screen, press Next button in the form - this will navigate to the next record:
SQL will execute one more time:
From the detail log, we can see that SQL execution event is logged as well, when there is activation event:
During normal scenarios, SQL is executed once and data stays in memory. Keep attention, how often passivation/activation happens in your system - this can affect performance significantly.
7 comments:
Hi,
Excellent post, as usual. I had a question about shared AM pools. I was testing with 1 AM connection (shared) and saw that the AM instance was "reset" in between different calls (was trying to load the same page with 2 browsers). Also saw the behavior where if there are more than 2-3 web calls, will get a PPR on the page (with AM connection exhausted).
What is the life cycle of Shared AM pool and when does, lets say, 1 instance not enough to be able to be shared among multiple requests.
Hi,
I believe this post might help you to get more ideas about Shared AM's and where these kind of AM's is used: http://andrejusb.blogspot.ca/2011/07/adf-code-corner-article-087-how-to.html
Thanks,
Andrejus
Thanks Andrejus,
What's the solution for this problem?
Solution is to tune AM properties - referenced pool in particular properly, according to estimated number of concurrent users.
Andrejus
Hi,
Nice post.But I am facing a slightly different issue in production. We have a Jspx page where we have dragged and dropped the VO object(data model) as table. In the view criteria, few fields are marked as selectively required so the user needs to enter a value in those fields to get the data.Executing just the VO query takes forever due to huge amount of data.
THe user normally opens 2-3 tabs for different pages among this one. The user migrated between different tabs for their operations. But we are seeing the VO query being triggered as is once in while even though the user hasn't searched for any data on that page for quiet a bit of time.It is not consistent but it seems that it is been triggered when the session timesout among the muliple tabs.I am not sure what event can cause that to trigger as it is not possible to just execute the VO query through the page due to few fields marked as selectively required.Any help would be of great help as a long running query is crashing the server (stuck thread on weblogic server)
Hi,
This is how it works - during AM activation, it will invoke SQL for passivated VO's. You should check when exactly this slow SQL is executed. I would recommend to set row fetch limit for VO instance. I was facing several cases, when WebLogic stuck threads were reported due to unlimited fetch from DB.
Andrejus
Hi. Thank you for the prompt reply. The query does have order by clause which is causing it to run forever.
For now I have programmatically added the order by clause using setOrderByClause in processQuery() method for the Search button. But I would really appreciate to know on the following.
1. Does the order by clause persist whenever the VO object SQL is excuted. For example once the search button is called, setOrderByClause is set, but if I have called vo.executeQuery somewhere else, will the order by clause still persist in that case?
2. When all the AM gets activated?
Thanks again in advance
Post a Comment