Thanks again. I am still interested in page stores though. I'm not saying
they are related to the expiration issue but I am curious how do they manage
themselves. I haven't been able to find much info online. Does each one
just store a potentially unlimited number of pages or is there some
couple of questions:
-what wicket version are you using?
-are you using httpsessionstore or secondlevelcachesessionstore (default)?
-what application server/container are you using?
-are you running the application in clustered environment? if yes,
what kind of load balancing do you have?
-do the
The project I work on uses Wicket 1.3.4 and we are using the default session
store (SecondLevelCacheSessionStore.)
The app is clustered and runs on WebLogic 8 through Apache. I'm not
entirely sure how those two are setup but I don't believe there is any
resource sharing between instances in a
Well, as far as I can tell, there is nothing special going on in
Wicket that might cause session expiration. Last visited page is
basically a normal session property.
To me this seems more likely to be servlet container / load balancer issue.
-Matej
On Thu, Jan 22, 2009 at 9:21 PM, UPBrandon
Thanks Matej and Igor. We are using sticky sessions (I can even see the
JSESSIONID in requests) and since a session sticks to a certain
server/instance, there shouldn't be any need for replicating sessions among
instances. There are dozens and dozens of web apps here and losing sessions
hasn't
Hi,
wicket holds the last accessed page in pagemap and certain number of
previous pages in DiskPageStore (serialized on disk). The last
accessed page should never be evicted from pagemap and even if it was,
it would still be stored on disk.
-Matej
On Fri, Jan 23, 2009 at 12:19 AM, UPBrandon
i will let matej answer the questions below in detail. the point still
is: the last accessed page is always stored in session so the
diskstore never even comes into play if all you are doing is hitting a
submit button on a form.
does websphere serialize sessions to disk under high load when it
In theory if websphere serializes session under stress and then
deserializes back the page indeed wouldn't be restored. But it would
still be in DiskPageStore, so when there is a request for that page
wicket can still load. Unless Webshere sends the unbind event - which
would make wicket delete
