[jira] Commented: (TAP5-463) PerThreadManager should have the ability to share thread state across multiple threads (for use in parallalizing processing)

["Howard M. Lewis Ship (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666970#action_12666970 ] 

Howard M. Lewis Ship commented on TAP5-463:
-------------------------------------------

It may, however, be necessary for many services that can be referenced (however indirectly) from the thread pool to upgrade any internal state to use proper synchronization semantics.  That is, currently a per-thread service can use simple instance variables and simple Maps.  Under this new system that would not be good enough, because multiple threads may share a single "perthread" service instance. This simply can't happen prior to this change ... and it brings into question whether this change is "safe".

> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.