This discussion is archived
1 2 3 4 Previous Next 48 Replies Latest reply: Aug 8, 2007 9:53 PM by 60437 Go to original post RSS
  • 15. Re: V3 Caching - any more info?
    135285 Oracle ACE
    Currently Being Moderated
    Hi Simon,

    yes the ApexLib Framework works with v3.0.

    There was a performance issue with one of the views, a fix is included in the version I'm releasing today. I'm also able to remove some restrictions of the framework, because the APEX 3.0 repository views contain now some previously missing columns.

    Patrick
    ----------------------------------------------------------------------------------------------
    Check out my APEX-blog: http://inside-apex.blogspot.com
    Check out the ApexLib Framework: http://apexlib.sourceforge.net
  • 16. Re: V3 Caching - any more info?
    VANJ Journeyer
    Currently Being Moderated
    The condtion (among other factors) is used to determine if the page/region should be retrieved from cache. The same condition is used to determine if the page/region just rendered dynamically should be written to cache

    Not sure I understand this.

    If the cache condition evaluates to true (and the cache timeout has not expired), the page/region will be retrieved from cache. If it evaluates to false, the page will be rendered dynamically.

    In either of these 2 cases, using the same condition to determine whether to write to cache doesn't make sense (to me).

    In the former case, it would write the same content back to the cache (and reset the cache "age").

    In the latter case, nothing would happen (since the condition evaluates to false).

    Could you please clarify some more? Thanks
  • 17. Re: V3 Caching - any more info?
    60437 Employee ACE
    Currently Being Moderated
    In the former case, it would write the same content back to the cache (and reset the cache "age").
    No, the cache doesn't need to be updated if the conditions all result in the cached version being retrieved, prepared, and sent to the browser. "The same condition is used to determine if the page/region just rendered dynamically should be written to cache."
    In the latter case, nothing would happen (since the condition evaluates to false).
    Correct.

    Scott
  • 18. Re: V3 Caching - any more info?
    VANJ Journeyer
    Currently Being Moderated
    Thanks, Scott. One more question, if you don't mind.

    Putting any value in the request will cause a page to be rendered dynamically

    So if a page has a couple of report regions that are NOT cached and other "expensive" content that IS cached...when either of the report regions need to paginate through their resultset, all the expensive regions will be rendered dynamically, thus slowing down the entire page? Any way to avoid this?

    [Using a PPR report template comes to mind, any other techniques?]

    Thanks
  • 19. Re: V3 Caching - any more info?
    60437 Employee ACE
    Currently Being Moderated
    PPR report templates are the obvious choice and all that come to mind for this specific situation.

    Scott
  • 20. Re: V3 Caching - any more info?
    369783 Newbie
    Currently Being Moderated
    Scott,

    I've looked at the documentation and at the new cache area on the region definition, and I'm still a bit fuzzy on the concept.

    I have a search page with a "Records Found" region. The region is conditional upon a field either not being null or not equaling '1=1'. If the user has selected some search criteria, then the field negates out the two possible conditions to not display the "Records Found" region.

    If the user selects one of the records and navigates away from the page to see further details and then comes back, the "Records Found" region re-executes the query to re-populate it.

    So, I can use the cache on a per user user basis (Cached By User) to avoid the region re-executing the query each time the user comes back to the page (as I understand it).

    How would I check whether to use the cache or not? When the user clicks the "Search" button, it already fires a process to build a where clause based on the user input, so can I still use the "REQUEST =" condition? Or should I specify in my process to clear the cache (I forget what the exact term is)?

    Each time the user refines their search criteria (and clicks the Search button), I'd want to clear the cache and re-execute the query, but if all they're doing is going back and forth from a detail page to the main search page again, I'd want them to use the cached search results.

    It seems like clearing the cache in my process that builds the where clause is the most logical place, but perhaps I'm missing something. (I've kind of thought and re-thought this out as I was trying to phrase this question properly).

    Thanks,

    Bill Ferguson

    It looks like if I put it in my process that builds the where clause, the proper procedure would be APEX_UTIL.PURGE_REGIONS_BY_PAGE, and this will cause the (maybe previously cached region) to re-execute (or execute) the query? Is there any exception handling to be done by me if the cache doesn't exist, like the first time a user executes a search?

    Message was edited by:
    wbfergus
  • 21. Re: V3 Caching - any more info?
    60437 Employee ACE
    Currently Being Moderated
    Bill,

    So, I can use the cache on a per user user basis (Cached By User) to avoid the region re-executing the query each time the user comes back to the page (as I understand it).

    Yes, if you know that the original result set is still good and all basic "use-from-cache" criteria are fulfilled ("the basic criteria" include: 1. no REQUEST value present in URL; 2. page is not a no-duplicate-page-submission-allowed page; 3. cached page/region exists in cache, for named user when applicable; 4. cached page/region is not stale; 5. certain session-state-protection conditions are met that we haven't installed yet; 6. the page is large enough to warrant caching; 7. cache-when condition is true; Some of these criteria apply to page caching only, not region caching.).

    How would I check whether to use the cache or not? When the user clicks the "Search" button, it already fires a process to build a where clause based on the user input, so can I still use the "REQUEST =" condition?

    You should build the page with conditions on the region caching so that it always does what you want. You shouldn't have to explicitly purge the cache in most cases. So the condition might be 'when P1_SEARCH is not null', expressed any way you like using standard conditions.

    Or should I specify in my process to clear the cache (I forget what the exact term is)?

    I'm not sure what you are referring to. If you mean the clear-cache action on branches or Session State process types that clear cache, those deal with session state clearing/resetting and are unrelated to this page/region caching feature.

    Each time the user refines their search criteria (and clicks the Search button), I'd want to clear the cache and re-execute the query, but if all they're doing is going back and forth from a detail page to the main search page again, I'd want them to use the cached search results.

    Right, so region caching is your friend. When you say "going back" I assume you mean using navigation controls on your page and not using the browser back button.

    It seems like clearing the cache in my process that builds the where clause is the most logical place

    The best way is probably to consider all the ways the page can be reached (branches, links from other pages, etc.) and use a convention of passing a certain item name/value in when you want the page to be dynamically generated (or the other way around, when you want a cached version to be used if possible). Then use that item in the cache condition on the cached region(s). If the situation isn't so complicated, just pass in a REQUEST value to cause the page to be rendered dynamically.

    ************

    Mike (mhichwa), the inventor of all this stuff, gave me a few points worth noting about page/region caching, building upon his comments earlier in this thread:

    Page Caching

    1. Use when entire page is static when typically run, for example when a search page is first used and no search criteria have been entered. See Mike's numbers about our "aria people home page" above.

    2. Use for pages that always have only "static web page"-type content.

    3. Use for dashboard-style pages that lend themselves to caching "by user".

    Using page caching for any of these cases can give you multi-fold performance improvement.

    Region Caching

    1. Use for regions that contain navigation controls such as Apex lists. These are relatively expensive to construct dynamically.

    2. Use for regions with purely static content.

    3. Use for regions that show "first set" of query results where those can be treated as "pseudo-static" (top 10 customers). Makes initial page load fast and PPR can be used to get the next set without refreshing the whole page.

    4. Use for dynamic content that doesn't need to be refreshed on each page visit and is relatively expensive to obtain: using a web service, a URL, or some sort of network query, for example a stock quote, or news from some xml feed.

    5. Use for dynamic content obtained from sources which themselves maintain periodically refreshed snapshots: reporting applications, data marts, and data warehouses.

    6. Use for charts on the above datasets. Not only is the chart region with the "embed" tag cached but the chart itself is cached making the re-execution of the query unnecessary.

    Using region caching for any of these cases can give you multi-fold performance improvement.

    General Usage Tips

    1. Avoid using REQUEST to control behavior during page "show" processing. In addition to the problem we've cited in the past, that the request value isn't preserved during certain events that submit the page and branch back to the same page, the presence of a request value disables page and region caching for the page view. To prevent these problems, developers should try to use session state inputs (pass in item names/values) to control the page during show processing.

    2. The number of cached versions of a page or region (in the database) is at most one per page/region per user. That is, there is no mechanism for user U to cache report region R results filtered for department 'D100' and to simultaneously maintain a cached version of region R for department 'D200'. The later region U-R displaces the first region U-R in the cache. So even though a page or region's cache-when condition might have various components, this conditional logic (assuming it evaluates to true) does not serve as a "tag" or differentiator of any kind for the cached content: the cache management code uses only the "basic criteria" described above in order to serve requested pages or regions from the cache. [I don't know if I described that well...we will correct it after further review if necessary.]

    Scott

    Message was edited by:
    sspadafo - added item (7) to basic criteria list
  • 22. Re: V3 Caching - any more info?
    Arie Geller Guru
    Currently Being Moderated
    Hi Scott,

    Very clear and informative post.

    One more issue if you don't mind. I understand the page and region caching, but when you are creating a new page, you have an option of creating multiple items, using tabular form. One of the columns in the form is "Cache", supposedly for each item. Can you clarify that?

    Thanks,
    Arie.
  • 23. Re: V3 Caching - any more info?
    60437 Employee ACE
    Currently Being Moderated
    Arie - that sets the Source Used attribute to "Only..." or "Always...".

    Scott
  • 24. Re: V3 Caching - any more info?
    369783 Newbie
    Currently Being Moderated
    Scott,

    Thanks for the clear explanation. That helps a lot.

    Bill Ferguson
  • 25. Re: V3 Caching - any more info?
    369783 Newbie
    Currently Being Moderated
    Okay, after Scott's (and Mike's) clear explanation above, I did a little experimenting.

    My navigation (other than the browser's back button) is through a DHTML Menu based upon a list. Creating a region item and then telling the Menu to set the field with a value a 'Y' didn't seem to work. I also set the field to 'N' within my process that generates a where clause for the region I want cached, and for some reason the Menu wasn't resetting that. I was using this field as a condition on whether or not to use the cache. (I also made the field displayable so I could see what was happening.)

    What I wound up doing was in my process that generates the where clause, I also used:
    APEX_UTIL.PURGE_REGIONS_BY_PAGE(:APP_ID,3); --3 is the page number

    This seems to be giving me the results I expected. Whenever a user changes the conditions for the display, it rebuilds the where clause for the search the region conducts, and "wipes out" the values from the cached region, so it will re-execute the query with the current where clause.

    It does however lead me to another question. Say I have 10 users on the system at once, and the process executes the PURGE_REGIONS_BY PAGE. Since it only accepts the application and page numbers, does this only affect the current users or does this purge all of the regions for that page across all users? The documentation does not explain if this is application-wide or only on a per-user basis. I'd hope that it's on a per-user basis, and that seems the most logical, but I can't test it today without any users other than me on the system.

    As Mike's description about region caching (#3) explains, if this is a cached report region, when the user navigates back to the page, it is back to the first result set. So if the user goes to like the 3rd or 4th result set, selects a record to navigate away from this page and subsequently returns through your application's navigation, the first result set is displayed again and the user will have to return to the result set they were on before manually.

    This is a bit of a pain, but overall it's much nicer than re-executing the query each time the user would return to the page after viewing another. In my case, it saves about 15-20 seconds.

    In my app, users will typically conduct a search. They'll try several permutations of a search to finally get the results narrowed down to a manageable level (just a few hundred records), and then they'll go back and forth from the search screen to the details of the selected record and then back to the search screen to look at (or edit) the next record. So, the region caching in this case does help by cutting out the re-execution of the query when the user returns to the search page. They may have to re-execute the query to get to the result set they were on before, but let's hope this will be a "future enhancement". (hint, hint)

    :^)

    Another very nice and cool feature. Thanks.

    Bill Ferguson
  • 26. Re: V3 Caching - any more info?
    60437 Employee ACE
    Currently Being Moderated
    Since it only accepts the application and page numbers, does this only affect the current users or does this purge all of the regions for that page across all users?

    I think you want to use this procedure instead:
    procedure cache_purge_by_page (
        p_application  in number,
        p_page         in number,
        p_user_name    in varchar2 default null)
    Scott
  • 27. Re: V3 Caching - any more info?
    369783 Newbie
    Currently Being Moderated
    Many thanks once again Scott!

    Bill Ferguson
  • 28. Re: V3 Caching - any more info?
    VANJ Journeyer
    Currently Being Moderated
    Scott:

    The same condition is used to determine if the page/region just rendered dynamically should be written to cache

    I am still having trouble understanding when the cache is read from and when it is written to.

    Here is my simple attempt at understanding this stuff.

    http://apex.oracle.com/pls/otn/f?p=24317:61

    The Dynamic Region is a HTML region with a Display as Text item P61_DATE that is set using a unconditional OnLoad computation to to_char(sysdate,'mm/dd/yyyy hh:mi:ss pm')

    The "Cached region" is also a HTML region with Region Source &P61_DATE. The cache-when condition is P61_USE_CACHE=YES. That P61_USE_CACHE is a Display as Text item in the Dynamic Region.

    There is a OnLoad computation to set P61_USE_CACHE to YES if it is NULL

    There is a After Footer Computation to set P61_USE_CACHE to NO if it is YES

    Clicking the New Search button submits the page and the same-page branch sets P61_USE_CACHE to NO

    Clicking the Go Somewhere button just redirects to a blank page and a button on the blank page redirects back to this page (just to test the caching behaviour)

    Clearly, the real-world use-case I am attempting to simulate is similar to Bill's. i.e. there is a expensive-to-render report region with many report filders. Each row on the report region has a Edit link that goes to a form page which edits that row. Clicking Save or Cancel on that Form page saves the data (or not) and redirects back to the Report page. The only time the Report should be rendered dynamically is when the search filters change, not when I come back from the Form page. I thought this is best implemented by passing a value from the same-page branch because the only time the same-page branch would kick in is when the search filters are changed and you click on the Search button. So that is what I did on the example above.

    My observations:

    1. When page is first rendered, both the timestamps are the same (good)
    2. When I click on Refresh/Reload on the browser, the dynamic timestamp changes but the cached one doesn't proving that the region is indeed served from cache (good)
    3. When I click on the New Search button, both timestamps are refreshed (not sure what this indicates)
    4. When I Click on the Go Somewhere button, wait a few seconds and come back to this page, I see that the cached region timestamp reverts back to the one in 1 & 2. Again, not sure what this means.

    I expected that when I click on the New Search button, the cached region would be rendered dynamically (because P61_USE_CACHE is set to NO) and the region just rendered dynamically would be written to the cache as per your quoted comment above. The write-back-to-cache doesn't seem to be happening.

    In any case, I don't understand how the same condition can be used to determine both when to read from cache and when to write to the cache (going back to your puzzling (to me at least) quoted statement above).

    Could you please clarify? Thanks
  • 29. Re: V3 Caching - any more info?
    Arie Geller Guru
    Currently Being Moderated
    Hi Vikas,

    Interesting example. I think the catch is that not using the cache is not like clearing it.

    In the first page load, your on-load process set cache to "Yes", and when refreshing the page you can see it's working. Then, Clicking the New Search button sets the cache to No. Both regions render dynamically, but no new cache is being saved – as reading and writing condition is the same. This is a different behavior then we are use to from our local browser cache. Then you go to a different page and your cache condition is set back to "Yes". The APEX engine renders the page from cache, but the only cache he can see is your first timestamp.

    This is why Bill needs to use the cache_purge_by_page procedure, because changing the search field itself is not enough if your cache condition is "When Not NULL".

    Regards,
    Arie.