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]
