I'd argue that there's "bigger fish to fry" than parallel rendering.
What's all the "work" that will benefit from parallelisation? Because the actual rendering itself is unlikely to see any significant time reduction by multi threading. I'd actually wager a bet that the overhead of managing the threads actually increases the rendering time. If it's the data retrieval that's taking the time, a cache or multi-threaded data retrieval is probably a better place to focus your efforts. On 4 Nov 2014 21:52, "Alex Kotchnev" <akoch...@gmail.com> wrote: > Lance - I'm not saying that doing this would work out of the box or that it > would be trivial , I understand that Tapestry as a framework has made > choices that might make this difficult or impossible. Yet, it's a cool > idea, in a way that a framework should be able to support its users (e.g. > "ah, you want these rendered in parallel, fine, let me do this for you" > kind of way). It seems like something that can be doable in Tapestry as > well, I'm just not entirely sure how . It certainly seems possible to > launch the "child threads" and have them have access to the parent thread's > ThreadLocals. > > Cheers - > > On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <lance.j...@googlemail.com> > wrote: > > > I'd say this is not a great idea. Tapestry assumes that rendering is all > on > > the same thread. The request and response (and other thread scoped > > services) will be null on a non-request thread for instance. Also each > > thread will have a separate hibernate session if using tapestry-hibernate > > which will need to be cleaned up and won't share a level1 cache. > > On 4 Nov 2014 19:57, "Alex Kotchnev" <akoch...@gmail.com> wrote: > > > > > I've been poking around Lift for the last few months and one of the > > > interesting approaches it has is that it can mark "snippets" (roughly > the > > > equivalent of tapestry compoents) as "parallel" - what Lift does w/ > > > snippets that are marked in parallel is that it fires up new threads > for > > > rendering those snippets and waits for all of them to complete before > > > rendering the page / final output. > > > > > > Seems like a cool idea - knowing that Tapestry stores its state in > > > ThreadLocal variables it seems that doing something similar wouldn't be > > > trivial. Would something similar be possible - e.g. maybe the "child" > > > threads can inherit the ThreadLocals of the thread that started them ? > > > > > > Anyway, it's just a curiosity question :-) After spending a > considerable > > > time learning and reading about Lift ( I liked some of the > > non-traditional > > > approaches that it takes to building web apps ) , my final conclusion > was > > > that Tapestry's component focused approach was superior ( I was quite > > > surprised that despite being "view centric" Lift didn't have a way of > > > coupling the snippet template and the snippet code into a cohesive > > > component). > > > > > > Cheers - Alex K > > > > > >
