Why should you avoid storing large objects directly as page fields?

In a stateful Wicket page, every field on the page (and on every child component) gets serialized into the session's page store, so a large object referenced directly as a field — a big collection, an image byte array, or a JPA entity with a deep object graph — effectively multiplies the memory and I/O cost of holding that page in the session, and it does so per user, per stateful page instance.

At small scale this is invisible; at real concurrency it becomes the classic Wicket scalability trap: session sizes creep up, page-store serialization gets slower, and if pages are persisted to disk under memory pressure, that disk I/O cost scales with how much unnecessary data each page instance is dragging along. It also risks NotSerializableException at runtime if the large object (or something it references) isn't actually serializable, which often only shows up once that exact code path executes in production.

The fix is almost always the same one used elsewhere in Wicket: wrap the reference in a LoadableDetachableModel (or an equivalent detachable pattern) so the session holds a lightweight identifier instead of the object itself, and the real data is fetched fresh only when actually needed for rendering.