Let's not advertise hacks :)
"Local view invocation are always processed on the same thread" is not
true at least for the async calls. Are there other cases?
If we agree, I can add a note of caution to the "Programming
Restrictions" section, that currently says this:
"The enterprise bean must not attempt to manage threads. The enterprise
bean must not attempt to start, stop, suspend, or resume a thread, or to
change a thread’s priority or name. The enterprise bean must not attempt
to manage thread groups."
-marina
Adam Bien wrote:
> Carlo,
>
> you don't have to challenge it. ThreadLocal is just a mostly working hack :-) I see it a lot in projects.
>
> I will have to write a post about: http://java.sun.com/javaee/6/docs/api/javax/ejb/EJBContext.html#getContextData() as well.
>
> ThreadLocal works in the majority of all cases (mostly everything is execute in the same thread).
>
> However: it is underspecified behavior. In most application server you can associate a bean with a certain thread pool. Then the context will get lost.
>
> But: is a transaction always entirely executed by the same thread locally? IMHO this should be clarified,
>
> thanks!,
>
> adam
>
> On 21.09.2011, at 15:01, Carlo de Wolf wrote:
>
>
>> I wish to challenge the assumptions made in http://www.adam-bien.com/roller/abien/entry/how_to_pass_context_with.
>> Not because it looks like a bad pattern, but more because it relies on un(der)specified behavior.
>>
>> Summary of the article: Context between EE layers can be passed via ThreadLocal.
>>
>> The one piece I can find in the spec only implies this behavior:
>> EJB 3.1 FR 4.8.5:
>> "That is, where an outbound call from a Singleton method results in a loopback call to the Singleton on the same thread."
>>
>> Given an invocation on a local view the assumption is pretty solid.
>> Assuming that there is no ThreadLocal possible in a remote invocation coming from another VM is very solid.
>>
>> The weakness comes when two EARs are deployed and one calls the other via a remote view.
>> Would this be a same thread invocation or not?
>> If so, deploying the EARs on different VMs would change the semantics of the remote view invocation (while still being a valid assembly).
>>
>> So I would like to see the answers to the following be put into spec:
>> - does a local view invocation imply a call on the same thread?
>> - does a remote view invocation imply a call on the same thread?
>>
>> My answers would be: yes, no.
>>
>> In short: A container may or may not process a remote view invocation on the same thread. A portable application *must not* rely on the thread context of such an invocation. Local view invocation are always processed on the same thread.
>>
>> Carlo
>>
>
>
>