No Post This Week
by Avrom
…well, except for this one. I’m trying to get my manuscript off to the publisher.
Tricks, Tips, Thoughts, and Rants About Java EE, Oracle ADF, and Web Application Development
Updates Mondays
…well, except for this one. I’m trying to get my manuscript off to the publisher.
Now that we’ve looked at tuning entity objects, associations, and, in three parts, view objects, lets look at tuning view links for best performance.
This is going to be a shortish post, because most aspects of tuning view links are similar to tuning associations. For example, in addition to affecting how new rows appear in view object instance result sets, view link consistency affects how new rows appear in view link accessor-returned rowsets, and you can use similar techniques to manipulate these accessors that I told you about for manipulating association accessors. And view links, like associations, can maintain accessor rowsets, with the same advantages and disadvantages of doing so.
But there’s one serious issue that comes up for view links that doesn’t come up for associations: Controlling view link query execution time. This can have such an amazing affect on dealing with bottlenecks in application performance that I’m surprised it isn’t discussed more frequently.
I’m back from the wilds of December, and to my regular schedule. I had intended to talk about view links this week, but I realized there were two important things about tuning view objects that I forgot to discuss in Part 1 or Part 2: View link consistency and in-memory filtering.
Like association consistency, view link consistency affects whether new rows appear in the query collections for accessors (view link accessors this time, rather than association accessors). But it does something more: It affects how new entity rows appear in the query collections of view objects.
The end of the year is a hectic time for most people, and I’m no exception. I’m not going to be able to get a post up this coming Monday, and I’ve realized that I’d only be kidding myself if I believed it wouldn’t happen again between now and the new year.
So I’ve taken down the “Updates Mondays” promise, effective through the end of December. It’s not that the blog is going on hiatus for that time; I’ll still try to get something up whenever I can. It’s just that until the new year, “Updates Mondays” is changing to “Updates When I Get the Chance.” I’ll be back on the regular, almost-every-week schedule after that.
Continuing on from the last post, we’re looking at ways to tune ADF view objects for optimal performance and resource management.
In most applications, the user needs to be able to scroll through data both forwards and backwards–to return to a previous row in addition to simply being able to scroll forward, or to find rows an earlier view row after finding a later one. Because of this, by default, once rows from a view object’s query result are read into the view cache, they stay there. If your JDBC fetch size is 18, then initially, only 18 rows will be in the view cache, but when request rows outside the first 18, that number goes up to 36, then 54, then 72, and so on.