Re: getRequestCycle null after session serializes

"Howard M. Lewis Ship" <[email protected]>
Newsgroups gmane.comp.java.tapestry.devel,gmane.spam.detected
Message-ID <007401c2ae8d$6a35fce0$3dc41e42@howardczkz2sl3>
I'd need to see a little more code to figure out what you are doing.  My guess is that you are expecting the same page instance to process your subsequent requests and that doesn't happen, especially with paging.

For something to survive from one request cycle to another, it must be stored in the HttpSession (directly) or indirectly as a persistent page property, or as part of the Visit.  Disabling caching forces out into the open these kind of problems, since you are guaranteed to never use teh same page instance twice.
  ----- Original Message ----- 
  From: Luke Galea 
  To: Tapestry Developer 
  Sent: Thursday, November 28, 2002 9:22 AM
  Subject: [Tapestry-developer] getRequestCycle null after session serializes


  Hello,

              I have a strange problem (well.. at least I think it's strange). I have extended BasePage for pages that need validation and access to the database. In my page I have a method: "getSession" that pulls the db connection data from the request cycle ( or checks if it is already there really ). 

   

  It works perfectly until I either: 

  1. Disabled page caching and refresh the page or click any links that involve a refresh

  2. With page caching on, wait 2-3 mins or so for the server-side session to be serialized ( that's my guess at least ) then try and refresh. 

   

  I noticed that in the FAQ it says that disabling page caching is a good way to: "test that you are persisting server-side state correctly".

   

  I believe I am doing this correctly, I don't see how even implementing this incorrectly would result in "getRequestCycle" returning null.. unless perhaps I am forgetting to call super() somewhere?

   

  Thanks in advance.

   

  Luke Galea 

  Software Development

  BlueCat Networks

  905-762-5225
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.