Components are not thread safe, and not intended to be used in this way - there would be a significant undertaking to make them cacheable, and the cost of the synchronization would likely far outweigh the current costs of component instantiation, etc...
Where you can make the biggest difference is caching your models. If you don't have to re-retrieve your model data, then you can get huge gains. Of course, if you thoroughly do your performance testing and find that your site really is so huge and has so much traffic that the extra instantiation is hurting you, the way to go is caching the generated markup with a frontend cache. -- Jeremy Thomerson http://www.wickettraining.com On Wed, Mar 24, 2010 at 2:15 AM, zkn <z...@abv.bg> wrote: > Hi, > > since Wicket uses session to store the components hierarchy for a page is > it possible to store parts of the hierarchy in the application context > instead of the user session? If it's not possible do you consider it worth > to add as feature request? > > What's the idea: imagine a home page of a website where eventually for a > short time of period( say 1 minute) the only dynamic component is a search > form( and that's only in case the user hits search). The rest of the page > consist of components that do not change for each user request - for example > a block of news. If 100 users hit the page simultaneously they will actually > see the same content in that block and there is nothing in that block that > depends on the user session. The content may change in few minutes when a > new article has been added. > > What if for example the developer has the option to make a component > cacheable by implementing specific interface which will give the developer > the option to use the cached version or render and possible store the new > rendered component in cache? > > Seems like this can significantly improve performance in certain > situations. > > Regards, > Ozkan > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
