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 >
