API / Apache Wicket Interview questions
What is the difference between page storage strategies (in-memory vs disk-based) in Wicket?
Wicket's IPageStore abstraction controls where stateful page instances actually live once they're serialized for the session, and the choice of implementation trades raw speed against memory pressure at scale.
| In-memory store | Disk-based / file store |
| Fastest access, no I/O overhead | Slower access due to disk I/O |
| Consumes JVM heap per stored page | Consumes disk space instead of heap |
| Risk of OutOfMemoryError under high concurrency with many large pages | Scales further per session before hitting hard limits |
| Good fit: low-to-moderate traffic, small page state | Good fit: high-concurrency applications with larger per-page state |
Wicket's default configuration commonly layers these together — a small, fast in-memory cache holding the most recently touched pages, backed by a disk-based store for older ones that get evicted from memory — so an application doesn't have to choose one strategy exclusively; it's tuning how much lives at each tier and how quickly pages get evicted from the faster tier.
What is the main trade-off between an in-memory page store and a disk-based one?
How do many Wicket configurations combine both storage strategies?
More Related questions...
