[Catalyst] FastCGI caching issue

Leandro Hermida softdev at leandrohermida.com
Wed Jul 7 17:45:57 GMT 2010


Hello,

I remember having a similar problem a long time ago, did you try
instead of no-cache to set the cache contol to no-store?  I remember
that no-cache didn't work but no-store works perfectly if you want the
web page to always reflect the latest data that is in your storage.

-Leandro

On Wed, Jul 7, 2010 at 2:54 PM, Steve <steve at matsch.com> wrote:
>  The problem has something to do with HTML::FormHandler and
> HTML::FillInField.  I verified that each request *was* hitting my
> application, and also that the database was getting hit as well.  What I
> discovered is that when I added a TT tag [% customer.email %] in addition to
> the tag for my HTML::FormHandler field - [% myform.fif.email %], refreshing
> multiple times resulted in the HFH value changing while the new [%
> customer.email %] tag got the correct value.  Seems like I need to further
> my understanding of HFH.
>
> Thanks for the help!
> Steve
> On 7/6/2010 9:33 PM, Toby Corkindale wrote:
>>
>> On 07/07/10 07:35, Steve wrote:
>>>
>>> The reference to $cachetime was found on the Catalyst Wiki:
>>>
>>> http://wiki.catalystframework.org/wiki/adventcalendararticles/2007/11-making_your_catalyst_app_cache-friendly
>>
>> In that instance, it's a variable used in some example code - it only has
>> any meaning within that example.
>> If you're using that whole end() block, then cool, but just setting
>> $cachetime=0; on its own won't do anything. The way you put it, it sounds
>> like you're considering doing that.
>>
>> I'd say it shouldn't be your first concern; everyone else tends to have
>> things like forms and pages work fine without needing to tweak that -
>> browsers already have some smarts in them to try and avoid caching dynamic
>> data.
>>
> I verified that the http header was changed, however this did not fix the
> problem.
>>>
>>> As of my last post, I had not implemented/acted on the $cachetime, but
>>> since then I've successfully set the http response header
>>> 'Cache-Control' to 'no-cache'. This has not solved the problem - Yes, I
>>> restarted my httpd server.
>>>
>>> At present, my cohort and I suspect that we are up against a database
>>> caching problem, but haven't completely ruled out anything. Am I better
>>> off asking the DBIC list?
>>
>>
>> Well, you haven't told us a whole lot about what the problem is, so it's
>> hard for us to agree or disagree with your diagnosis.
>
> I've got a customer form.  I have the app open in three different browser
> tabs (different browsers, different computers yield same result).  The
> following chain of events results in the old values being rendered by my
> form:
>  1) I set the email address for customer 'Walmart' to 'wally at wm.com' in one
> tab, then save it.
>  2) In the next browser I edit the same customer, changing the email field
> to 'sam at wm.com', and save it.
>  3) In the last browser I edit the same customer, changing the email field
> to 'dave at wm.com', and save it.
>  4) I go to any of the three browser tabs and refresh.  The value toggles
> between the three values.
>
>> I'm still a little confused/concerned by your comment that "my session
>> seems to 'cross' over to other fastCGI processes"; it sounds a bit like you
>> are misunderstanding what the session is *meant* to do, and thus, perhaps
>> the problem lies there.
>>
> I misspoke.
>>
>> Run your app with Debug mode enabled, and watch the logs - you will be
>> able to see if you're hitting the app, or getting a cached copy. If you add
>> some debug statements in your form handling, you can also see what data
>> you're getting back from the database.
>> You might also want to enable DBIC_TRACE in your environment, to get a
>> /lot/ of SQL dumped out too.
>>
>>
>> Best of luck,
>> Toby
>>
>>>
>>> Steve
>>>
>>> On 7/6/2010 4:23 PM, Tomas Doran wrote:
>>>>
>>>> On 6 Jul 2010, at 19:26, Steve wrote:
>>>>
>>>>> however my session seems to 'cross' over to other fastCGI processes
>>>>> (I've got 3 fastCGI processes running).
>>>>
>>>> Yes, they'll do that.
>>>>
>>>>> I've googled around and even tried to set $cachetime = 0 in my
>>>>> Root.pm controller's END action.
>>>>
>>>> Er, what is $cachetime? What are you expecting it to effect.
>>>>
>>>>> Can anyone point me in the direction of a fix? If I've not provided
>>>>> enough background info let me know and I'll expand.
>>>>
>>>> Please expand.
>>>>
>>>> If you suspect code, please attach code.
>>>>
>>>> Cheers
>>>> t0m
>>>>
>>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.830 / Virus Database: 271.1.1/2986 - Release Date: 07/06/10
>> 14:36:00
>>
>>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>



More information about the Catalyst mailing list