CODEWITHSUNDEEP
cachingwicketwicket-6
zeratul021
zeratul021

Reputation: 2694

Wicket Page cahing in DefaultPageStore

Recently I've overridden Wicket's DefaultPageStore methods serializePage and deserializePage and enhanced them with logging to track time spent in them.

I discovered that deserializePage is never called because the actual page is always retrieved from the SessionEntry#sessionCache.

I suspect this is due to my page setting setVersionPagesByDefault(false) which creates the situation where there is only current version of a page which is serialized in the SessionEntry and then (needlessly) in the DefaultPageStore from where it's never deserialized.

If this suspicion is correct, I'm then able to make method serializePage a no-op a and skip serialization, which currently takes 3 or 7 seconds (DeflatedJavaSerializer) for page X.

I did not detect any side-effects so far, so my question is: is this safe? And if not, then why?

I'm considering this only as temporary solution until I'm able to move the data from the page to proper cache.

Upvotes: 1

Views: 503

Answers (1)

Maciej Miklas
Maciej Miklas

Reputation: 3331

Here is some info on page versioning: http://wicket.apache.org/guide/guide/versioningCaching.html

If you do not need support for back button, you can disable page versioning - it has not side effects, assuming that your pages handle back button correctly. Jumping back to the page that has no state can create page without initial parameters. Like for example: you jump from page A to B and provide some arguments to B. Now user is on page C and clicks back button. This will result in redirect to page B, but no arguments will be passed this time. If you would use page versioning, wicket would only deserialize page B and execute rendering again.

Here is also one possibility to disable page store: http://maciej-miklas.blogspot.de/2013/09/wicket-6-disable-page-serialization.html

Upvotes: 1

Related Questions