Oracle ADF: Shooting your own leg examples - Part I

Hello world!

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.

For my first post I have decided to spent some time to present and try to clarify the importance of some tuning parameters:

• "in Batches of" (FetchSize) and AccessMode tuning attributes of View Objects.
• FetchSize of af:table property
• Iterator Range Size. (@ Bindings - executables)

These are some of the tuning parameters that someone has to really take care if she needs to have a healthy and fast ADF application. Many people have tried to explain how to tune ADF applications, but I realize that in real projects developers cannot really apply these best practices. In my understanding one of the reasons that this is happening is because "tuning" and performance excellence in production deployment is not always a concern of the development team. Most of the times the concepts around tuning the artifacts that developers work are purely understood or even worse heavily misunderstood!

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.

Stay tuned...