This is the last in a series of posts about tuning business components. The complete list:
The last post was about understanding application module pooling, so I’m going to assume you understand it now. And if you understand application module pooling, you can understand the pain points from a performance perspective, and you can gain some idea of how to balance out differing concerns. Here are the pain points, in decreasing order of importance.
Last week, I talked about a couple of tuning opportunities for ADF application modules: Lazy loading and shared application module instances. This week and next, I’m going to talk about a way to tune your application modules that is, in my opinion, even more important: Knowing how and when to adjust your application module pool settings. This week, I’m going to write about what application module pooling is; it’s pretty vital that you understand it before you try to tune it. Next week, in the final post in the ADF BC Tuning series, I’ll provide the actual application module pool tuning tips.
Continue reading ADF BC Tuning VIII: Application Modules, Part 2
It’s been a while since the last installment of ADF BC Tuning, but it’s time to start it up again. I’ve already posted tips for tuning entity objects, associations, view objects (in three parts), and view links, so now, let’s turn our attention to the last of the major business components: application modules.
Now that we’ve looked at tuning entity objects and associations, we’ll turn to talking about tuning your ADF view objects for good performance and memory management. There’s a lot to say about tuning view objects (more than for any other business component, in my opinion), so I’m going to break this topic up over two posts. This week, we’ll discover the reasons for and against basing read-only view objects on entity objects, learn how to control how much data is fetched into the middle tier at one time (and how to optimize this for your particular case), and talk about what passivation of view objects is and how to control whether and how much of it happens. Next week, we’ll talk about query-level range paging, forward-only mode, and the spill-to-disk feature for handling very large caches.
Continue reading ADF BC Tuning III: View Objects, Part 1
Last week, I introduced the ADF development methodology I’m proposing, “Extreme Reusability,” articulated its goals, and discussed the techniques of “Generalize, Push up, and Customize” and “Think Globally, Deploy Locally” that are critical to the methodology. I didn’t, however, describe the actual…well, methodology, meaning the development cycle prescribed by Extreme Reusability.
Notice I didn’t say the application development lifecycle. That’s because developing under Extreme Reusability, like developing under SOA, isn’t primarily about the creation of standalone applications. You should think of the development cycle for extreme reusability as part of an enterprise-wide effort.
Development under Extreme Reusability involves developing along three separate but interacting (and communicating–communication is absolutely vital under this system) tracks: framework development, service development, and application development. These tracks are assigned to different individuals on the team, in (at a guess–remember this is a proposed methodology) somewhere around a 20-60-20 division for a typical organization’s needs.
Continue reading Extreme Reusability, Part II