Seems possible; it would be most useful for doing background work in parallel.
On Tue, Apr 14, 2009 at 6:24 PM, Fernando Padilla <[email protected]> wrote: > Could you ever support a true Request Scope, instead of the PerThreadScope? > > That way we can have multiple threads per request? > > (of course services implemented as request scope will have to be > multi-thread compliant to be used in the manner I'm proposing). > > Howard M. Lewis Ship (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/TAP5-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Howard M. Lewis Ship closed TAP5-463. >> ------------------------------------- >> >> Resolution: Won't Fix >> >> The more I think about this, the more dangerous (from a thread-conflict >> point of view) it is. >> >>> PerThreadManager should have the ability to share thread state across >>> multiple threads (for use in parallalizing processing) >>> >>> ---------------------------------------------------------------------------------------------------------------------------- >>> >>> Key: TAP5-463 >>> URL: https://issues.apache.org/jira/browse/TAP5-463 >>> Project: Tapestry 5 >>> Issue Type: Improvement >>> Components: tapestry-ioc >>> Affects Versions: 5.1.0.0 >>> Reporter: Howard M. Lewis Ship >>> Priority: Minor >>> >>> I'm looking into options to perform more behaviors in Tapestry lazily >>> and/or in parallel threads. A very nice aspect of Tapestry IoC is that all >>> per-thread state is stored in a single Map stored within the >>> PerThreadManager service. >>> It is conceivable that that Map could be made into a ConcurrentHashMap >>> and shared between threads. This would allow per-thread (i.e., per-request) >>> state to be shared across multiple threads. >>> The eventual goal is to automatically make use of thread pools and the >>> Future operations to allow processing of certain method invocations to occur >>> in parallel in other threads. There are pitfalls; for instance, Hibernate >>> Session is not thread safe, so not only would you not want to parallelize >>> it, and you'd have to be careful that no spawned threads indirectly make use >>> of it. >>> I'd expect the additional api for PerThreadManager to have methods: >>> Runnable prepare(Runnable r); >>> Invokable<T> prepare<T>(Invokable invokable); >>> These methods would wrap the provided operation to properly initialize >>> the PerThreadManager for a new thread (along with any cleanup after invoking >>> the provided operation). A thread from a thread pool could invoke the >>> returned Runnable and it would take care of initializing the PTM's >>> thread-local map along with any other setup and cleanup details. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
