RE: Store models short-term
Thanks dretzlaff for your reponse. Indeed overriding detach elicits the
behavior I desired. Per your warnings, I should determine if this approach is
really more efficient. I wonder how many occasions in my programming career
I've assumed my way is best, when the complete opposite is true...
Date: Fri, 4 May 2012 15:15:08 -0700
Subject: Re: Store models short-term
From: dretzl...@gmail.com
To: users@wicket.apache.org
Hi, Jason. Welcome to Wicket!
If you want to tie an entity to a page, best save the entity within the
page itself. You can do this by using a simple o.a.w.model.Model. If you
don't want to detach between requests, then LDM is not a good fit.
There are use cases where serializing entities at the app level (instead of
the database) makes sense, such as wizards where saving prematurely results
in an invalid data model. However, if your motivation is simply performance
then I suggest you verify your assumptions. Retrieving entities by primary
key is generally very fast, and if it's not fast then it's because it's
really large and you probably don't want that serialized in the session
anyway. The optimization is especially moot in clusters where the
undetached entities are replicated across the network as part of the HTTP
session. And there are other disadvantages such as having to deal with
detached entities, with potentially stale state.
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.
Best of luck,
Dan
On Fri, May 4, 2012 at 2:40 PM, JASON HOLT j_holt5...@msn.com wrote:
I'm new to Java and Wicket. My only previous experince with web
applications has been with Asp.net forms (not MVC). Please be patient;
coming from the postback event paradigm, I'm struggling to grasp the
concepts in Wicket. In my simple scenario, assume there is no AJAX. I need
to build the model from a database. If I use an LDM, on a postback Wicket
calls to the database to rebuild the model before updating it with the new
values. But if I don't use an LDM, Wicket will serialize the model in the
PageMap. I would like to keep the model 'in memory' long enough to process
the postback to avoid unecessary calls to the database, but release it when
I have moved on to a different page. I thought of something like this... In
the LDM @Override
public Object load()
{
...somehow get the session.
if (session.getAttribute(PageAModel)!=null)
{
return (PageAModel)session.getAttribute(PageAModel);
}
else
{
PageAModel pageAModel = ...build from database.
session.setAttribute(PageAModel, PageAModel);
return pageAModel;
}
} Then in the Page... @Override
public void onSubmit()
{
PageAModel pageAModel=(PageAModel)session.getAttribute(PageAModel);
...update the database with PageAModel pageAModel =
(PageAModel)ldm.getObject();
... //removes the model from session?
session.setAttribute(PageAModel)=null;
this.setResponsePage(...);
} I suspect there is a better way to handle this. Can I avoid using an
LDM, but somehow remove the model from the PageMap after leaving the page?
Re: Store models short-term
On Fri, May 4, 2012 at 6:15 PM, Dan Retzlaff dretzl...@gmail.com 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 http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Store models short-term
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 jer...@wickettraining.comwrote: On Fri, May 4, 2012 at 6:15 PM, Dan Retzlaff dretzl...@gmail.com 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 http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Store models short-term
I'm new to Java and Wicket. My only previous experince with web applications
has been with Asp.net forms (not MVC). Please be patient; coming from the
postback event paradigm, I'm struggling to grasp the concepts in Wicket. In my
simple scenario, assume there is no AJAX. I need to build the model from a
database. If I use an LDM, on a postback Wicket calls to the database to
rebuild the model before updating it with the new values. But if I don't use an
LDM, Wicket will serialize the model in the PageMap. I would like to keep the
model 'in memory' long enough to process the postback to avoid unecessary calls
to the database, but release it when I have moved on to a different page. I
thought of something like this... In the LDM @Override
public Object load()
{
...somehow get the session.
if (session.getAttribute(PageAModel)!=null)
{
return (PageAModel)session.getAttribute(PageAModel);
}
else
{
PageAModel pageAModel = ...build from database.
session.setAttribute(PageAModel, PageAModel);
return pageAModel;
}
} Then in the Page... @Override
public void onSubmit()
{
PageAModel pageAModel=(PageAModel)session.getAttribute(PageAModel);
...update the database with PageAModel pageAModel =
(PageAModel)ldm.getObject();
... //removes the model from session?
session.setAttribute(PageAModel)=null;
this.setResponsePage(...);
} I suspect there is a better way to handle this. Can I avoid using an
LDM, but somehow remove the model from the PageMap after leaving the page?
Re: Store models short-term
Hi, Jason. Welcome to Wicket!
If you want to tie an entity to a page, best save the entity within the
page itself. You can do this by using a simple o.a.w.model.Model. If you
don't want to detach between requests, then LDM is not a good fit.
There are use cases where serializing entities at the app level (instead of
the database) makes sense, such as wizards where saving prematurely results
in an invalid data model. However, if your motivation is simply performance
then I suggest you verify your assumptions. Retrieving entities by primary
key is generally very fast, and if it's not fast then it's because it's
really large and you probably don't want that serialized in the session
anyway. The optimization is especially moot in clusters where the
undetached entities are replicated across the network as part of the HTTP
session. And there are other disadvantages such as having to deal with
detached entities, with potentially stale state.
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.
Best of luck,
Dan
On Fri, May 4, 2012 at 2:40 PM, JASON HOLT j_holt5...@msn.com wrote:
I'm new to Java and Wicket. My only previous experince with web
applications has been with Asp.net forms (not MVC). Please be patient;
coming from the postback event paradigm, I'm struggling to grasp the
concepts in Wicket. In my simple scenario, assume there is no AJAX. I need
to build the model from a database. If I use an LDM, on a postback Wicket
calls to the database to rebuild the model before updating it with the new
values. But if I don't use an LDM, Wicket will serialize the model in the
PageMap. I would like to keep the model 'in memory' long enough to process
the postback to avoid unecessary calls to the database, but release it when
I have moved on to a different page. I thought of something like this... In
the LDM @Override
public Object load()
{
...somehow get the session.
if (session.getAttribute(PageAModel)!=null)
{
return (PageAModel)session.getAttribute(PageAModel);
}
else
{
PageAModel pageAModel = ...build from database.
session.setAttribute(PageAModel, PageAModel);
return pageAModel;
}
} Then in the Page... @Override
public void onSubmit()
{
PageAModel pageAModel=(PageAModel)session.getAttribute(PageAModel);
...update the database with PageAModel pageAModel =
(PageAModel)ldm.getObject();
... //removes the model from session?
session.setAttribute(PageAModel)=null;
this.setResponsePage(...);
} I suspect there is a better way to handle this. Can I avoid using an
LDM, but somehow remove the model from the PageMap after leaving the page?
