Nice.
ps - I have this dream of actually parallelizing the render cycle :) At
least in minimal ways.. etc etc..
Howard Lewis Ship wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
