On 24.03.2010, at 09:23, Jeremy Thomerson wrote: > 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...
I see this could be a problem especially for with Java 1.4. With concurrency packages in Java 1.5 I believe this could easily be made thread safe with almost no cost for synchronization. > > 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. Yes, but still keeping the rendered html for complex read-only components would be the fastest possible way. > > 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. I was first considering this approach especially with bookmarkable urls this could become beautiful. But would Wicket really allow using frontend cache cause it relies on user's session to handle form submits, ajax actions etc...? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
