probably because serialization is not guaranteed. you can use a http session store on a single node cluster and never have anything serialized.
-igor On Fri, Oct 16, 2009 at 12:00 AM, Daniel Frisk <dan...@jalbum.net> wrote: >>> Pushing definitely is more performance efficient - you know exactly >>> when and where you push it and it's easy (happy-day-scenario) to >>> optimize. Partly the ease of optimization results from "difficulty of >>> making complex relations". >> >> I would expect push to put more load on your servers due to >> serializing to second level cache, and getting a page back from that >> cache might also be more expensive. Of course, it depends where you >> pull from. And then when you're within one request, you probably have >> that data you'd push already in memory (e.g. Hibernate's session cache >> if you use that), so it might not be more expensive in that sense >> either. I do agree that pull models can lead to more complex >> structures, but that also depends on what kind of models you use (e.g. >> reflection based models actually can save code, but obviously using >> lots of anonymous classes won't). :-) >> >> Eelco >> > > > A third option, which from my POV is perhaps the most elegant, is to roll > your own page store that serializes the pages instantly after the request. > The serialization have special hooks to replace entites or whatever that you > would prefer to have as LDM with a placeholder that just stores the type and > id when serialized. When/if the page is later deserialized you get the > entity fresh from your object repository (cache). > > Why is this elegant? You get the programming model of push with the benefits > of pull without writing any code for model proxies. I have communicated this > idea before but nobody but me seems to prefer it, I'm actually surprised :-) > > // Daniel > jalbum.net > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
