tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: [jira] Closed: (TAP5-463) PerThreadManager should have the ability to share thread state across multiple threads (for use in parallalizing processing)
Date Wed, 15 Apr 2009 20:39:30 GMT
Seems possible; it would be most useful for doing background work in parallel.

On Tue, Apr 14, 2009 at 6:24 PM, Fernando Padilla <fern@alum.mit.edu> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry
Director of Open Source Technology at Formos

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message