Chris, Exactly. The Mid-Tier would not need to go get the objects (again) on startup. ( So what value would the prefetch really have at that point?)
I would also note that to my knowledge when you choose to "flush the cache" (which is unfortunately needed some times) then the persistent cache is "wiped clean" and the prefetch is NOT used to get it back to a "starting point" either. You have to stop the Mid-Tier and start it to trigger the prefetch stuff. So if prefetch is only used on startup, and a persistent cache trumps fetching all those objects again then I just do not see the usefulness of the prefetch. I guess it might help after you flush the cache and restart the Mid-Tier. ( However that has for a long time felt more like a workaround to various bugs in the Mid-Tier than a standard practice that we should be doing. ) In my shiny (dream) universe.... I tend to think that it would be "better" if the Mid-Tier(s) could talk to each other and propagate changes to their caches between themselves. So when the first Mid-Tier sees that "Object X" changed it warns the others in the cluster, gets the new def, fixes it's cache and then "shares" it's cache with the other Mid-tiers. ( You know, like the Admin thread does for the worker threads in the AR System server.) ) The load on the ARS server(s) is lower on NodeN startup conditions from Mid-Tiers and the user experience might be more consistent. ) Dealing with self caching clusters where one of the nodes is "stuck with a bad cache" can be difficult to identify in the first place. Example: Some users see the field, others do not. Heck, even knowing which Mid-tier the user was using behind the load balancer can be an adventure if your not doing Mid-Tier logging and grepping through those files. ) No "Prefetch" is needed. The first Mid-Tier to start up uses it's persistent cache, if any, and the next Mid-tier get's a copy of the then current cache from the first one. (Already updated based based on user activity.) But maybe it is just me... -- 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 Wed, Sep 24, 2008 at 12:36 PM, strauss <[EMAIL PROTECTED]> wrote: > My understanding is that the persistence (which finally actually worked in > 7.1.00.002) is the feature whereby the pre-fetched cache (and possibly plus > anything fetched after that - I'm not sure of that) is retained in a file so > that if you restart tomcat (or it crashes and restarts), the persistent cache > file is re-read in less than one minute as opposed to the 24 minutes that it > normally takes to build it from scratch on my system. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > >> -----Original Message----- >> From: Action Request System discussion list(ARSList) >> [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black >> Sent: Wednesday, September 24, 2008 11:04 AM >> To: arslist@ARSLIST.ORG >> Subject: Re: Remedy mid-tier precache XML code >> >> All, >> >> In general, I thought the general idea of a "prefetch" was eclipsed by >> the idea of a persistent cache that was only updated as needed? You >> know like what the User Tool is designed to do.(Starting in v7.1 of >> the Mid-Tier.) >> >> Or am I mixing metaphor here? >> >> I personally dislike the idea that when a Mid-Tier (or AR Server) >> starts up it has to "suck down" all of this application definition. It >> seems to me that in a cluster configuration that behavior can lead to >> some DB performance issues if you have enough nodes starting up at the >> same time. (And thus effect existing nodes and users that are not >> currently starting up.) >> >> -- >> 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 Wed, Sep 24, 2008 at 11:50 AM, Axton <[EMAIL PROTECTED]> wrote: >> > What would be nice would be if the mid-tier kept a count of the >> > forms/number of times accessed by various 'group sets', then gave the >> > option to automatically generate/update the prefetch xml file based >> on >> > the stored data. Would be even nicer if there were a knob to enable >> > the automatic update of the prefetch xml file based on the stored >> data >> > on a periodic basis, say when the servlet container was stopped. May >> > be too progressive an idea though. >> > >> > Axton Grams >> >> _______________________________________________________________________ >> ________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
