Hi Mohan,
1. Yes, it is outside the scope of this spec. Each Java EE Product
Provider could decide if and what they want to do with respect to how to
clean up ThreadLocal in pooled threads. But I would imagine that most
providers would clear up the security related information from a pooled
thread before reusing the thread for another task.
2. In that example, the priority refers to the priority in a
java.lang.Thread.
3. It is entirely up to application developers what kind of applications
they can develop with the APIs provided by the spec.
Hope that helps.
Regards
Anthony
On 2/4/13 9:53 PM, Mohan Radhakrishnan wrote:
> Hi,
>
> 1.
> I have a general question that probably applies to all thread
> pools but in this spec. threads are explicitly managed by the
> container. Are there any rules regarding 'ThreadLocal' required ?
> Since the container manages the threads apart from the fact that they
> are pooled there could be application security restrictions on the
> sensitivity of information stored by ThreadLocals.
>
> Is this outside the scope of the spec ?
>
> 2. What is the meaning of the requirement of a slightly higher
> priority ? Does this actually mean that internally a
> java.util.concurrent Queue or something like that handles this ?
>
> 3.1.4.1.3 OLTP Thread Pool
>
> The OLTP (On-Line Transaction Processing) Thread Pool executor uses a
> thread pool with many more threads and a low hung-task threshold. It
> also uses a thread factory that creates threads with a slightly higher
> priority and a ContextService with a limited amount of context
> information.
>
> 3. Are high-throughput OLTP applications envisaged by the adoption of
> the spec. ?
>
>
> Thanks,
> Mohan