API / Apache Wicket Interview questions
Why do we use LoadableDetachableModel instead of a plain field reference?
A stateful Wicket page is serialized into the session so it can be resumed on the next request, and any object a component field points to directly gets serialized right along with it — which becomes a real problem when that object is a large, non-serializable, or frequently-stale entity like a JPA-managed row pulled from a database.
LoadableDetachableModel breaks that direct reference: instead of the component holding the entity itself, it holds the model, and the model's load() method fetches the entity fresh only when getObject() is actually called during rendering, then the reference is cleared again in detach() at the end of the request. The session ends up storing a lightweight model plus whatever identifier load() needs (like a primary key), not the full object graph.
This solves three problems at once: it keeps the session small regardless of how large the underlying entity is, it avoids serializing objects (like JPA proxies) that often aren't cleanly serializable in the first place, and it guarantees the data is re-fetched fresh on each render rather than showing a stale copy from an earlier request.
More Related questions...