This is my very first post... I have waited a long time, before I took the decision to stay more time... awake and share with you my ideas and my experience in various technology areas.
I will start my journey in sharing knowledge with Oracle ADF. More specifically I plan to write a small series of articles on how to try "no to shoot your own leg" while developing with ADF.
I believe that Oracle ADF is a mature framework and so all the related blogs or books for it. Since I have not been involved with ADF early in its development, I will try to avoid writing things that have already presented by others. I will try to focus on concepts and techniques, that I generally find that are not well understood by ADF developers. I will do this by either presenting some serious mistakes that I have seen in real production code, or I will create some fictitious errors or bad practices in order to present a better development approach.
How to bring and ADF application down... Learning from mistakes.
- "in Batches of" (FetchSize) and AccessMode tuning attributes of View Objects.
- FetchSize of af:table property
- Iterator Range Size. (@ Bindings - executables)
One the other hand and if developers are well informed about the effects that their choices in configuration parameters make, will make them at least more cautious and ready to face the real problems. Real problems come, when their application get out of the lab. So in this context, I believe that one of the many ways that we can learn is through studying the "bad examples". Bad examples can show us how can a production deployment of our code can really suffer from our choices made during development and poor designed testing. We can learn what to avoid and possibly provide an incentive to search for a better solution.
I often find that simple APIs or complex frameworks are not correctly used due to misconceptions. Examples and tutorials usually document the typical way of using an API, but usually miss showing what can go wrong in various choices that a developer can make. In my understanding this drives ones thinking in one direction. As a consequence the "obvious" pitfalls that an experience architect or developer can identify, are left out of the visibility of the average developer.
Coming back to the tuning parameters mentioned earlier, I will first describe how you can set a combination of the above attributes that can really bring a production environment on its knees! I will set the "bad example" and I hope to learn from it...
Then I will try to present how you could possibly diagnose such a situation on a Weblogic server running on JRockit with JRockit Mission Control.
And finally I will explain the "obvious" (or not "obvious" is for you to decide) problematic set of values that lead to the performance degradation and how to resolve the problem setting the right values.