On 09/23/2011 10:53 PM, Marina Vatkina wrote:
> Let's not advertise hacks :)
Hacks and unforeseen usage are what most great inventions are made off. ;-)
Carlo
>
> "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
>>
>>