How does Wicket manage component state across requests?

For a stateful page, Wicket keeps the actual constructed Page object — and its full tree of child components, with their current field values — alive in the user's HttpSession between requests, rather than rebuilding it from scratch each time.

When a user submits a form or clicks a stateful link, the request's callback URL identifies which specific page instance and component in the session's page store should handle it, and Wicket deserializes (or retrieves, depending on the store implementation) that exact instance, invokes the relevant method (onClick(), onSubmit()), and then re-renders and re-stores the updated page. Wicket keeps a limited number of historical versions of a page per session (configurable) so the browser's back button can still work correctly against an earlier, still-available version rather than the very latest one.

Pages are stored using a pluggable IPageStore, which can keep them purely in memory, spill older or larger ones to disk, or be swapped for a custom implementation — giving applications control over the classic trade-off between memory usage and how much page history is retained.