tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-463) PerThreadManager should have the ability to share thread state across multiple threads (for use in parallalizing processing)
Date Sat, 24 Jan 2009 18:29:59 GMT

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

View raw message