[Catalyst] FastCGI caching issue

[Steve]

  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
>
>