Hello Alex, I can't see what would be better with parallel component rendering. As far as I know, parallelizing things improve performance. In the context of a web application performance is really needed when there are multiple clients sending requests at the same time. As each request has its own thread, parallelizing can be considered as already in motion.
IMHO, if you need to speed up things for a single request rendering, you may have more problems when thousands of people will hit your website at the same time. Cheers, Charles 2014-11-04 22:51 GMT+01:00 Alex Kotchnev <akoch...@gmail.com>: > 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 > > > > > >
