LJ, That is my understanding.
Be default the prefetch is done on "start of the Servelet Engine" and not after a "dump cache". (But maybe that changed in v7.1?) Mid-Tier-710.pdf pg: 78 " If you flush the cache in the Configuration Tool, any prefetched forms you specified beforehand are flushed from the memory cache. The prefetch process is performed again for these forms the next time the web server is restarted. " So it looks like it did not change to me. However the doc also says this: Mid-Tier-710.pdf pg: 73 " Click Flush cache to update the objects already in the cache with the latest versions on the AR System server. " So... maybe some of the docs were not fully updated for v7.1? Or maybe some portion of them is just misleading? (or both?) ( ignoring the dump cache button for the moment ) If you have the "Persistent Cache option" turned on, and you restart the Mid-Tier it would, spend time serializing the cached objects then likely would update only the "prefetch" objects on startup, but would also still have any other objects that were successfully serialized during the last shutdown too. (However, there are also some interesting performance tuning notes about a possible need to alter your shutdown time/processes to allow for the objects to be serialized too. The comments are specific to Tomcat, but I would think that the same issues would apply to all Servlet containers.) Now exactly how that all works with the "Flush cache" feature... My guess is that the flush cache simply deallocates the in memory cache and nothing else. It _might_ not even remove all of the serialized objects. Possibly, and maybe especially if you immediately shutdown the servelet engine. If so then a flush followed by a shutdown should yield no new serialized objects and would lead to "no extra" startup time. (Because the prefetch process likely just fetches the objects even if they are already current.) However, if the "Persistent Cache" option is used then the Flush followed by a shutdown sequence might be faster than without the Persistent Cache option. It might be that the previously serialized files might still be left laying around on the file system and the startup process might still benefit from them. Well, that is when these serialized objects really have not changed. :) (or so one would hope.) For a test system.... You might be ahead to simply decrease the "Definition change check interval" setting (to something small like 5 or 10) and let the Mid-Tier just manage its cache "normally". Assuming they have all the details working properly then I would bet that would be the most effective path. You could make the change, wait 15 minutes, then send the email to the testing team. :) Yes they might see it sooner than that... but that should not confuse them to much, even if they were working at those exact minutes. :) For production deployments... the same config might be your best bet. The cost of checking if the objects have been updated should be very small for the application/web server. HTH -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 10/17/07, LJ LongWing (Head) <[EMAIL PROTECTED]> wrote: > Isn't the perl script just a 6.3 substitute for the 7.1 prefetch.xml (or > whatever it's name is)? Lets see if I can get this straight...in 7.1..if I > want to dump and re-cache I need to press the flush button in mid-tier > config, and then restart the tomcat/servletexec to have it prefetch? > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > Sent: Wednesday, October 17, 2007 9:54 AM > To: arslist@ARSLIST.ORG > Subject: Re: 353 Error > > Joe, > > Or it might be an internal Mid-tier problem that goes something like... > " Oh.. I need to go fetch/cache that form... so I have nothing to show you > right now.. So.. User you go away and when you come back then I will be > ready for you." (thus give an error once and start the cache process for > that form) > > A strange thing about the "dump" cache tool is that it does not trigger a > recache (prefetch, or otherwise) operation. I would actually expect that the > function should mark all of the cache as "old" and then force a recache of > all items already in the cache. However it appears to only "dump and stop". > Then the Mid-Tier waits for the next user to "pay the price" for the lack of > a cache. > > > LJ, > > ( Just a thought. ) > > There was also a perl script that was used with the v6.3 Mid-Tier to "login > and force the server to cache objects". (Basically just simulating a user > activity of opening the form.) Maybe if your development process > incorporated such a step you could stop "dumping" > the cache all together? > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > On 10/16/07, Joe D'Souza <[EMAIL PROTECTED]> wrote: > > ** > > > > In addition of checking out the bug that Michael pointed out, take a > > SQL log at the time the error occurs to verify what the system API's > > are trying to access at the time of the error. It might reveal something > about your error. > > > > > > Joe D'Souza > > <snip> > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) > > [mailto:[EMAIL PROTECTED] Behalf Of LJ LongWing (Head) > > Sent: Tuesday, October 16, 2007 4:17 PM > > To: arslist@ARSLIST.ORG > > Subject: 353 Error > > > > > > ARS 7.1 > > Mid-Tier 7.1 > > New Atlanta ServletExec 5.0.0.13 > > Java 1.5.0_11 > > Windows 2003 > > > > We are working in a Test environment and every time we drop code from > > Dev to Test we flush the web cache to ensure that the latest code is > > available to the testers. We use the Application list on the left of > > the home page with entry points heavily on a home grown app. > > Sometimes, some of the users will click on an entry point and get a > > 353 error. Excerpt from Error Message Guide > > > > 353 Error > > You have no access to form. > > You are not allowed to access the specified form. Form permissions do > > not allow you to get the definition of the form or of its fields or to > > access the data it contains. > > Contact your AR System administrator if you need access to the form. > > > > The funny thing is if they didn't have access to the form...they > > wouldn't see the entry point. Even stranger, if they try again > > immediately after it works, and continues to work until we flush the > > cache again. I'm thinking it's a bug in Mid-Tier 7.1...but can't be > > sure. Anyone else seen this problem? Oh...and it only manifests > > itself in Mid-Tier of course...so no client interaction with this app. > > > > LJ LongWing > > RAC 7.x Certified > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
