Yes, you still deal with detached entities
(LazyInitializationException, StaleStateException, last writer wins, etc).
And worse in my opinion, it makes things different when responding from the
latest page vs. a page recovered with the back button, or if another
window/tab has made an intervening request. It's this reason that I'm not a
huge fan of the optimization in the first place. It's added another layer
of complexity to a couple of debugging sessions in the past year or so.

But since suppressing detach() is so easy and exactly satisfies the
requirements, I figured it was worth mentioning with a caveat. And I do
appreciate your emphasizing the caveat. :)

On Sat, May 5, 2012 at 2:31 PM, Jeremy Thomerson

> On Fri, May 4, 2012 at 6:15 PM, Dan Retzlaff <> wrote:
> > I'll mention one hack for which another Wicket user should rightly
> > reprimand me. As I mentioned recently, Wicket keeps the most recently
> > accessed page is a deserialized state to optimize serving the next
> request.
> > All components are still detached, but if you override IModel#detach() in
> > your LDM and suppress super.detach() then your entity will hang around.
> > This has the behavior you describe, since (1) the entity does not need to
> > be reloaded on subsequent requests, and since it's object reference is
> > transient (2) it goes away as soon as another page is accessed, and (3)
> it
> > does not get replicated among the cluster.
> >
> Well, you admitted you should be reprimanded.... :)  Doesn't that hack
> still leave you with lots of problems like stale/detached entities etc?  I
> definitely would not recommend that hack to someone new who is just trying
> to learn Java *and* Wicket.  I'd instead say (like you started off with)
> "don't prematurely optimize, learn and get experience with the new way of
> doing things and make sure you 150% understand them (and everything else
> that's going on) before trying to 'fix' things".
> --
> Jeremy Thomerson
> *Need a CMS for Wicket?  Use Brix!*

Reply via email to