API / Apache Wicket Interview questions
How do you configure detachable models to avoid memory leaks in the HttpSession?
- Extend LoadableDetachableModel<T> for any model wrapping data pulled from a database, cache, or other external source, implementing only
load()to fetch the object fresh each time it's actually needed. - Store only what's needed to re-load the object as the model's own field — typically a primary key or identifier — rather than any part of the loaded object graph itself, so what actually gets serialized into the session stays tiny regardless of how large the loaded entity is.
- Avoid capturing the loaded object in closures or nested anonymous classes that might themselves get serialized as part of a component, since a detachable model can still leak a heavyweight reference if something else holds onto the object after
load()returns and never releases it. - Let Wicket's automatic detach cycle do its job — it calls
detach()on every model touched during a request automatically, so this rarely needs manual triggering, but a model class that overridesdetach()should always callsuper.detach()to preserve that cleanup behavior.
The underlying discipline is the same one that shows up across most Wicket performance advice: the session should hold pointers and identifiers, not full object graphs, and detachable models are simply the standard mechanism for enforcing that discipline consistently rather than relying on every developer remembering it by hand.
More Related questions...